I think it would be cool to install the packages in the same directory as the pyproject.toml.
Other popular frameworks already do this (PHP [composer], nodejs [yarn, npm], java [maven], rust [cargo], Ruby [bundle]) and it’s very useful for IDEs and etc… This way also is great to avoid to install or lean how to use additional tools if you work on multiple project on your machine.
Just to be clear I’m not asking to remove the option to install globally but to support an additional way to have the packages locally in the project
Typically people use a virtual envronment (conventionally called .venv) in the project root. Lots of tools support this convention. Alternatively, PEP 582 proposes something along the lines of what you’re suggesting.
Also remember that a project may have multiple disjunct dependency
sets, so you don’t necessarily want all of its possible dependencies
installed together (and in some cases that may not even be possible
due to conflicting dependencies or versions thereof between sets).
Tools like tox solve this by managing multiple venvs in a
subdirectory of the project, which can each have different sets of
installed packages.
Thanks for replying very quick, your alternative way looks more or less what I was looking for.
The PEP is almost 5 years old… why is not approved? Python is lagging behind all the other majors languages because of this
I’m not entirely sure about your first recommendation? it looks like an overengineering and complex solution, I’m not sure of the use case for that tool? And based on the comment of @fungi looks like very buggy and you need even more tools for it, other languages only required to change an argument or env var or config why do I need to learn 2 or 3 additional tools.
From my point of view it’s like trying to be able to upload pictures and the recommendation is to learn kubernetes and event sourcing they potentially do the job but there’s way more simple solutions and more fit for the job
yarn doesn’t use any virtual environment (or any other package) and as per your comment looks prone to be broken. So I need to learn how virtual environment package works first. I think everyone coming from any other major language will find it confusing and overengineering as I do.
You’re not doing your arguments any favours by insulting existing Python solutions. There’s nothing buggy about virtual environments, and the fact that you’ve not learned how they work is your problem, not ours.
If they aren’t willing to learn how Python’s approaches work, then yes, they may well do so. Personally I find Javascript’s solutions confusing and over-engineered. But that’s because I haven’t made the effort to learn them, or to understand the problems they are designed to solve. I don’t blame the Janascript tool developers, or expect them to change things just because I don’t understand their decisions.
Expecting a different language ecosystem to act just like one you’re used to is foolish - if all languages were the same, why would there be any point in having more than one language in the first place?
The venv module is part of Python’s standard library. I didn’t say
it’s broken, just that you may want multiple different conflicting
sets of dependencies installed (as an example, for running different
kinds of tests of your software), and venvs are a way to isolate
those different sets of packages from each other.
Sorry pretty much a standard across the whole industry PHP [composer], nodejs [yarn, npm], java [maven], rust [cargo], Ruby [bundle] feel free to find one, except python, that doesn’t. I didn’t mean to make you feel offended, I do apologize.
Virtual environment looks like docker or vagrant or virtualbox and I’m not looking to learn/use any of those and I feel like that is out of the scope for my request so I’ll stop replying to those message to avoid my request gets a diversion
It sounds like you’re getting triggered by use of the word “virtual”
in this context. While the subdirectory structure the packages get
installed into does look a bit like a chroot, it’s really not the
same thing as a virtual machine or a docker-style kernel container.
It’s just a local directory (inside your project directory if you
like) where the packages you’ve requested get installed. Since you
can have multiples of these and put them anywhere you want, there’s
commands or options you use to indicate which one to use when
running things.
OK, fair enough. In which case the answer to your question is PEP 582. And to answer your follow-up question about why it hasn’t been implemented yet, “because there’s not a consensus that it’s a good idea yet”.
There’s not much more to say. You may not like the fact that we’re still debating PEP 582, and you may not like the other solutions that people in the Python community use. That’s fine, you’re entitled to your views. If it’s too much of an issue for you, maybe stick with a language you’re more comfortable with - nobody here is forcing you to use or like Python. Maybe keep an eye on PEP 582 and come back and have another look at Python when it (or an alternative approach) is accepted.
Understood, it’s a pity the only real option is stuck for 6 years I’ll try next week to keep on track with this PEP to see what can be done without impacting people with different workflows/approaches like yours and others.
