Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
keradus opened this issue Jul 13, 2022 · 2 comments

Comments

@keradus
Copy link
Contributor

keradus commented Jul 13, 2022

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
Copy link
Member

theseer commented Jul 14, 2022

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
Copy link
Contributor Author

keradus commented Jul 15, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants