php: Use fetchFromGitHub instead of fetchurl.

[drupol]

Motivation for this change

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[drupol]

@ofborg build php74

[drupol]

@ofborg build php80

[drupol]

@ofborg build php81

[jtojnar]

• Could you explain what is the purpose of this change. (And also in the commit message.)
• The commit message should be prefixed by maintainers/team-list: and php: tags, respectively.
• I believe we already discussed switching from published tarballs to fetchFromGitHub in the past but I cannot find any other reference than php74: init at 7.4.0 #73151 (comment).
• This will also break users of generic.nix like nix-phps but we probably should not consider this a public API.

[drupol]

• Could you explain what is the purpose of this change. (And also in the commit message.)

I though it would be cleaner to use fetchFromGitHub than fetching a single url from php.net.
It makes sense to me to download sources from Github.

Also, I would like to provide snapshot builds (relates to fossar/nix-phps#35), so I though this would
be a first step towards it (even if we are not there yet!)

* I believe we already discussed switching from published tarballs to `fetchFromGitHub` in the past but I cannot find any other reference than [#73151 (comment)](https://github.com/NixOS/nixpkgs/pull/73151#discussion_r347748862).

I guess I was not using Nixos at that time, I don't remember such discussion.

* This will also break users of `generic.nix` like [nix-phps](https://github.com/fossar/nix-phps) but we probably should not consider this a public API.

Yep, we can update it accordingly on our own quite easily.

[AndersonTorres]

• Could you explain what is the purpose of this change. (And also in the commit message.)

I though it would be cleaner to use fetchFromGitHub than fetching a single url from php.net. It makes sense to me to download sources from Github.

I don't see such a necessity.
First, Github is not something so special to be put on a higher priority than other possible source repositories.

Second, fetchurl is simpler and more intuitive than fetchFromGitHub and the other fetchers. It should be used always when possible, or at least you should have a strong reason to prefer other fetchers than fetchurl.

Third, and related with second, the Github sources are not necessarily exactly the same as the tarballed ones. Sometimes the upstream project runs a prepare-for-release script before generating the release tarball (something like run autoconf and automake to generate the configure script).
Just look at the various occurrences of autoreconfHook + fetchFromGitHub in Nixpkgs.

Fourth, and expanding the third, if the upstream project provides their own links instead of relying on Github automated facilities, I think we should follow them in that regard. Until proven otherwise, we should trust them.

Also, I would like to provide snapshot builds (relates to fossar/nix-phps#35), so I though this would be a first step towards it (even if we are not there yet!)

What about an overlay outside Nixpkgs?

[AndersonTorres]

P.S.: this commit title message is the most misleading I have seen.
I was thinking in a huge restructuring of Nixpkgs, and it was just restricted to PHP...

[drupol]

Thanks for all your comments, it's clearer.

Sorry for the PR title, next time I'll prefix it correctly.

I will close this PR now.

[drupol]

Sorry to dig up an already closed topics, but wouldn't it be a good idea to switch to Github so @r-ryantm can create automatic pull-requests as soon as a new tag is pushed?

[Ma27]

How is this related to GitHub? r-ryantm IIRC uses repology for versioning information and can also update packages that don't do fetchFromGitHub.

[drupol]

I don't think it's possible to do since we are using a specific URL for downloading the PHP tarball.

[ryantm]

r-ryantm uses various sources of new versions including GitHub releases (for derivations using fetchFromGitHub) and repology.

[drupol]

@ryantm PHP release tarballs are fetched here: https://github.com/drupol/nixpkgs/blob/master/pkgs/development/interpreters/php/generic.nix#L300 I doubt that it can be automatized by @r-ryantm.

[AndersonTorres]

The bots should conform to Nixpkgs "api", not the reverse. It looks easier to update ryantm bot instead of butchering Nixpkgs.

Also, the bots are our helpers. They should make our lives easier, not us making their lives easier.

After all, without Nixpkgs none of those bots has a reason to exist.

[drupol]

I definitely in favor of using bots, I found this idea amazing !

What I just suggesting here is to use fetchFromGitHub so the bot is able to provide a new PR automatically when a new tag is published.
What I'm suggesting here is precisely to use the bot and reduce the manual mambo-jambo.

AFAIK, r-ryantm has never been involved into updating PHP in the past and using fetchFromGitHub would definitely fix that.

[AndersonTorres]

I definitely in favor of using bots, I found this idea amazing !

What I just suggesting here is to use fetchFromGitHub so the bot is able to provide a new PR automatically when a new tag is published. What I'm suggesting here is precisely to use the bot and reduce the manual mambo-jambo.

Then you should do more than merely change the fetcher, because surprise, different sources do not necessarily correspond to the same output.

AFAIK, r-ryantm has never been involved into updating PHP in the past and using fetchFromGitHub would definitely fix that.

Then you at least should investigate if the source can be replaced instead of supposing it.

Further, remember that r-ryantm is just a dumb builder. If github sources need some preparation, it is your job to provide them (and provide that they will not break in future releases).

[AndersonTorres]

Just to be not misinterpreted here: changes are welcome and I encourage them, however remember to trim the edges and ensure that the new configuration does not destroy an otherwise working release.

[drupol]

Hi @AndersonTorres ,

Thanks for taking the time to explain! I'm glad to have some challenges, and my motivation is not gone! :)