search

marwanhawari / stew

🥘 An independent package manager for compiled binaries.
MIT License
193 stars 14 forks source link

multiple binaries per project #2

Closed AFriemann closed 2 years ago

AFriemann commented 2 years ago

Hey there,

really like the project! (I actually had an old abandoned python project doing pretty much the same: https://github.com/AFriemann/ghbin)

one thing I noticed while testing is that I can't easily use it for projects that come with multiple binaries like for example ksniff: https://github.com/eldadru/ksniff

I had to manually remove the zip and re-install it. A multi select in the initial installation would be an awesome addition!

marwanhawari commented 2 years ago

Hmm this might be out of scope. stew was initially designed for simple projects that use a single binary. I'm not sure how I would implement multiple binaries per asset. It wouldn't work with the current implementation of stew uninstall <binary> and stew upgrade <binary>. Would upgrading 1 binary also mean upgrading the other binary for that asset? For something like https://github.com/eldadru/ksniff you might be better off using the kubectl installer.

Still, this would be nice to have but I would want to make sure the implementation is intuitive.

I'm open to suggestions.

AFriemann commented 2 years ago

Would upgrading 1 binary also mean upgrading the other binary for that asset?

I would definitely think so, yeah.

If you don't think it's in scope that's understandable - what I would suggest at the very least is a flag to ignore the existing archive to allow multiple runs for a project (and potentially a configuration parameter in the lockfile for it? Otherwise this will probably also cause issues during updates..). Yes, ksniff you could install using one of the usual plugin managers, but there are a bunch of other projects that are distributed in a similar fashion.

Without looking at the code I think it should be possible to add easily (essentially having done the same thing in ghbin) but I completely get the hesitance. I'm also still quite useless when it comes to golang though :)

marwanhawari commented 2 years ago

Would upgrading 1 binary also mean upgrading the other binary for that asset?

I would definitely think so, yeah.

I'm not sure if I agree with this actually.

what I would suggest at the very least is a flag to ignore the existing archive to allow multiple runs for a project (and potentially a configuration parameter in the lockfile for it? Otherwise this will probably also cause issues during updates..)

Right now there is a 1:1 relationship between a binary and its archived (or non-archived) asset that was downloaded. stew won't let you download an asset that has already been downloaded. stew isn't set up to handle a many:1 relationship between multiple binaries and a single asset because when you go to upgrade/uninstall a binary, stew looks for the associated asset and deletes it.

I think for the time being I'm going to hold off on this feature.

gdevenyi commented 1 month ago

Running into this issue with https://github.com/SUPERCILEX/fuc where I'd like both cpz and rmz