search

phar-io / phar.io

Website of the phar.io project
https://phar.io
45 stars 53 forks source link

Feature idea: repositories.xml - support not only GH releases, but also shim packages #130

Open keradus opened 2 years ago

keradus commented 2 years ago

Example tool: https://github.com/FriendsOfPHP/PHP-CS-Fixer/

Right now, Phive/phar.io is only reason why we are uploading phar files to GitHub releases: https://github.com/FriendsOfPHP/PHP-CS-Fixer/releases/tag/v3.9.3 (files: php-cs-fixer.phar, php-cs-fixer.phar.asc)

I wonder if we could have if possible to have an option to read phar files also from dedicated shim releases? like https://github.com/PHP-CS-Fixer/shim/tree/v3.9.3 (files: php-cs-fixer, php-cs-fixer.asc)

theseer commented 2 years ago

The answer to this comes in two folds ;)

First: Technically, from phive's perspective, it would require a new type of resolver. Finding a tagged release is easy, as Github (and others) provide an API to query for tags. We probably also can somehow fetch the tree information via API - haven't checked for that. But from then on it gets a bit difficult. I don't know how to generically find the shim file, as you do not attach .phar to it, it could be anything. We could probably try to find a .asc file and see if we can find a file named identically but without the .asc.

That should work for this project but I'm not sure if that qualifies as a generally viable approach?

Second: I fail to see the benefit of this shim repository over the github releases? It's a seperate project that has no (obvious) relation to the upstream project, requires additional commit and tag handling and in general makes finding - and downloaidng - pre-compiled assets generally harder for no - to me - obvious gain. So, why? :-)

keradus commented 2 years ago

First: Technically, from phive's perspective

I think technically doable even without API, you can parametrise like https://github.com/{repo}/raw/{version}/{filepath}, and maybe expect filepath to be same as project ID in phive structure, or to be passed as attribute in XML file, passed later to the resolver as parameter.

Second: I fail to see the benefit of this shim repository over the github releases?

there are bunch of ppl who likes to download phar file via composer, instead of whole source project. this is useful especially for tools like Fixer, phpstan etc, that allow ppl to avoid problems with dependency (my project requires that library in version X, but Fixer requires it in version Y, I cannot have them in same place).

We come up, over time, with different approaches - distribute phar file over own website (extra effort from our side), share via github releases, share via Phive, suggest to install via composer in separated folder (eg dev-tools)... quite popular and handy option is shim approach, nowadays.

As creator of tool, having so many different approaches is extra effort for me and if I could limit it, it would make my life easier. And since in my surroundings I do not know any dev who is downloading the phar file from GitHub Releases (they do source project, or phar via phive, or phar via shim), I want to limit this burden for me, especially as having so many other options around to download the phar file from.