I don't like the new `install`/`uninstall` approach

[felipecrs]

Hi,

Not that my opinion should count, but I thought why not let you know anyway.

I disliked how pkgx@2 is handling install/uninstall. For example, pkgm:

• Pollutes the system a lot more than before (/usr/local/pkgs, /usr/local/lib, /usr/local/bin, maybe more?)
• Makes it substantially harder to cleanup
• Makes it easy to break installations (if some of the dirs are removed, there won't be pkgx to recover it)
• Uses sudo without user consent, which makes me nervous as I often have systems with sudo NOPASSWD

Yeah, I know applications installed with pkgm do not depend on pkgx. But what for? To save 5MB in the whole system?

I thought the only pain-point of the pkgx@1 approach was the stubs speed. But that was solved with pkgx@2.

Why not make pkg@2/pkgm behave like pkgx@1 install used to?

• It's super quick to install (stubs)
• It doesn't download or consume disk until the program is actually used
• No crazy places to look for leftovers like /usr/local/lib, users can peacefully rm -rf "${PKGX_DIR:-"${HOME}/.pkgx"}" to free up disk without sacrificing anything at all

I use pkgx a lot in containers. In Dockerfiles, I use pkgx to ship stubs for applications that might be used. After installing the stubs, I can clean ~/.pkgx (and other dirs like ~/.cache/pkgx and ~/.local/share/pkgx) in the Dockerfile itself to guarantee the stubs are really only summing bytes to the final image size, without sacrificing functionality.

In fact, why not bring install/uninstall commands back into pkgx@2?

It would probably only add like 1KB in pkgx@2 binary size and yet would simplify things a lot:

Right now, to stub a program like go with pkgx mash pkgx/stub go, pkgx will have to download a hundred megabytes of stuff like deno and then deno will have to download the libraries, etc. And don't forget now there are additional places to clean up like ~/.cache/deno to bring the system back to a clean state.

I understand that X stands for execute in pkgx, and M stands for manage, separate responsibility, etc.

I also understand that install/uninstall in pkgx@1 were kinda hacky.

But also, I think pkgx aims to solve real-world challenges doing whatever it takes (like patching cargo in Pantry to install stuff to the right dir). Thus, an argument like that (keeping responsibility of code separated in different projects) doesn't makes sense in my opinion. That's oriented to the developers of pkgx only, not to users.

What if we can think of a future-proof, stable, install/uninstall solution based on stubs that wouldn't be hacky? I'm confident we can build something (example). Even for Windows.

Or just feel free to disregard this completely. No hard feelings. I'm very thankful anyway.

[jhheider]

sounds like a vote for #34.

moving to pkgm for visibility there.

[mxcl]

There is a mash script that does the same as the old install approach. pkgm is to satisfy the folks who wanted real installs.

pkgx^2 won't get install as we now have other tools for such things keeping everything “tight” in scope. sub-cmds on pkgx was a bad idea since it made it ambiguous what would happen if you did pkgx foo.

All the same I totally relate. Mostly I have shims rather than installs locally. Hence I made the mash script and documented it in the pkgx README,

[mxcl]

Uses sudo without user consent, which makes me nervous as I often have systems with sudo NOPASSWD

The other option is to insist on sudo to invoke, which maybe would be better for ~/.local vs /usr/local. Dunno. The current way it works minimizes the amount of code running sudo to the bare minimum which seems preferable.

[mxcl]

Right now, to stub a program like go with pkgx mash pkgx/stub go, pkgx will have to download a hundred megabytes of stuff

To clarify, mash has no deps and neither does the stub script (bar pkgx). pkgm needs deno however.

Mash does cache the scripts so you would need to clean that up admittedly. We could add a --no-cache flag to the mash script.

Like we could add a --no-install flag to pkgx too, so you’d do:

pkgx --no-install mash --no-cache pkgx/stub foo

Which would “install” mash (which has no deps, so is super fast) to a temp dir and run the mash script from a temp dir and voila! you get your stubs without clean up.

[felipecrs]

How about re-implementing pkgm in Rust? 😅

It's very lazy for me to say that, given I'll probably not be the one coding it, but it would solve my issue. I would not mind shipping pkgm in my container if it were just a few extra MBs.

[felipecrs]

There is a mash script that does the same as the old install approach. pkgm is to satisfy the folks who wanted real installs.

All the same I totally relate. Mostly I have shims rather than installs locally. Hence I made the mash script and documented it in the pkgx README,

Are these folks who want real installs a majority?

If not, maybe it's a good idea to demote real installs to a more specific command like pkgm full-install, and document it as a niche case command of which only advanced users should tinker with.

And then promote shims to pkgm's main use case. I expect most users to look no further than that.

[mxcl]

Are these folks who want real installs a majority?

People are stuck in their ways—yes. Installs are also safer, some software expects a tool they use to be installed and fails otherwise. In general we should recommend full installs as a result.

How about re-implementing pkgm in Rust?

We will when it is stable. Same as we did for pkgx.

Regarding sudo with NO_PASSWD, we could presumably detect that and then force a confirm from the user. It is not our intention to sudo without warning.

[mxcl]

We no longer call sudo for you (once the next version is released).