161–170 of 428 posts
Earlier quoted context omitted.
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
Earlier quoted context omitted.
I don't understand how things like this get approved into PEPs.
And people were laughing at PHP comments configuring framework, right?
Earlier quoted context omitted.
Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…
Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…
This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available.
> You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment.
True, but it's not best practice to do that because while the tool gets installed globally, it is not necessarily linked to a specific python version, and so it's extremely brittle.
And it gets even more complex if you need different tools that have different Python version requirements.
Earlier quoted context omitted.
Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
"pip freeze" generates a lockfile.
That’s very much not a lock file, even if it is possible to abuse it as such.
Earlier quoted context omitted.
Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…
Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…
Earlier quoted context omitted.
Just because you don't understand it, it's ok to call it an "anti-pattern"? Reproducibility is important in many contexts, especially CI, which is why in Node.js world you literally do "npm ci" that installs exact versions for you. If you haven't found it necessary, it's because you haven't run into situations where not doing this causes trouble, like a lot of trouble.
Just because someone has a different perspective than you doesn't mean they don't "understand". Lockfiles are an anti-pattern if you're developing a library rather than an application, because you can't push your transitive requirements onto the users of your library.
I've replaced the linkbait title with an attempt at saying what the feature is. If there's a more accurate wording, we can change it again.
I don't feel strongly, but as a uv author, I found "local dependencies" misleading. It's more like "uv's killer feature is making ad-hoc environments easy". When we talk about local dependencies in the Python packaging ecosystem, it's usually adding some package on your file system to your environment. The existing title made me think this would be about the `[tool.uv.sources]` feature. Really, it's about how we crea…
Earlier quoted context omitted.
I don't feel strongly, but as a uv author, I found "local dependencies" misleading. It's more like "uv's killer feature is making ad-hoc environments easy". When we talk about local dependencies in the Python packaging ecosystem, it's usually adding some package on your file system to your environment. The existing title made me think this would be about the `[tool.uv.sources]` feature. Really, it's about how we crea…
Sorry dang, didn't know the practice + got a bit emotional haha. I agree with the remark above, my message is rather on how easy it is to run python scripts with dependencies (without mutating the state.
Earlier quoted context omitted.
The PEP page is really good at explaining the status of the proposal, a summary of the discussion to date, and then links to the actual detailed discussion (in Discourse) about it: https://peps.python.org/pep-0723/
I see this was accepted (I think?); is the implementation available in a released python version? I don't see an "as of" version on the pep page, nor do lite google searches reveal any official python docs of the feature.