pypa
Is pipx-like functionality in scope for Hatch?
I like to use a unified UI for packaging-related tasks. One pretty important use case to me is installing CLI tools in one virtual environment per package, which is the role of pipx. Right now, Hatch fits many of my needs, and it will fit more when inline script metadata is implemented, but pipx is a tool I can't replace with Hatch, nor with any other unified tool that I know (Poetry or PDM).
From my understanding, a goal of Hatch is to be a one-stop-shop tool. Would pipx-type functionality fall in scope?
I have thoughts on the UI for installation features (on which I've been drafting a kind of blog post lately), but I'd already like to know if you (@ofek) would agree to the general principle.
Yes that is in-scope however just FYI it is unlikely that I would reimplement that but rather simply use pipx. There is a trend now in the code base where functionality that might not be used by everyone and requires dependencies get their own internal virtual environment that Hatch manages. For example, in the next release for projects that do not use Hatchling as their build backend there is an environment that uses build and for the fmt command there is another that has Ruff.
Does that sound fine to you?
Perhaps I don't have a good grasp of how hard to implement pipx's functionality is. I thought it would be relatively simple to do in Hatch using its existing environment management facilities, but I might be underestimating the complexity as I haven't looked much at the code yet. (I am prepared to do implementation work but I don't know when I'll have the time.)
Having the support in Hatch using pipx under the hood would already be nice.
Of note, one example in that to-be-published blog post is that when I upgrade Python with the Fedora package manager, I need to figure out which virtual environments to recreate (since they break), so I have to find which tool puts its venvs where, for each venv-managing tool I use. From that perspective I would prefer having the venvs in question under ~/.local/share/hatch/ rather than ~/.local/pipx/.
More generally speaking, I'd like harmonious integration of these environments with hatch env (with the exact UX to be determined). I fear this would be more complicated to do if the implementation strategy is wrapping pipx, but again I may be mis-estimating things here.
Okay, makes sense. I will think more about the implementation but know that no matter what this will be a feature!
Just to have an idea, are you generally open to feature contributions in Hatch, or is it still in a stage where you prefer to lay the foundations of features that expand the project scope like this yourself?
For this specifically, I would be open to a contribution for the wrapper approach and you can take a look at https://github.com/pypa/hatch/pull/1018 as an example. The reimplementation I would only be open to after you enumerated everything that pipx does so we both have a sense of the scope. I know it does extra stuff like rewriting scripts but I don't know everything about it.
aside the dogma of "a one-stop-shop tool", what is the rationale for not using pipx?
