131–140 of 428 posts
Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
I don't understand how things like this get approved into PEPs.
As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Hot take: pnpm is the best dx, of all p/l dep toolchains, for devs who are operating regularly in many projects. Get me the deps this project needs, get them fast, then them correctly, all with minimum hoops. Cargo and deno toolchains are pretty good too. Opam, gleam, mvn/gradle, stack, npm/yarn, nix even, pip/poetry/whatever-python-malarkey, go, composer, …what other stuff have i used in the past 12 months… c/c++ do…
I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great
1: https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271
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.
The requirements.txt file is the lockfile. Anyways, this whole obsession with locked deps or "lockfiles" is such an anti-pattern, I have no idea why we went there as an industry. Probably as a result of some of the newer stuff that is classified as "hipster-tech" such as docker and javascript.
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.
As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Caveat: I'm a node outsider, only forced to interact with it But there are a shocking number of install instructions that offer $(npm i -g) and if one is using Homebrew or nvm or a similar "user writable" node distribution, it won't prompt for sudo password and will cheerfully mangle the "origin" node_modules So, it's the same story as with python: yes, but only if the user is disciplined Now ruby drives me fucking b…
That said, I agree that `npm i -g` is a poor system package manager, and you should typically be using Homebrew or whatever package manager makes the most sense on your system. That said, `npx` is a good alternative if you just want to run a command quickly to try it out or something like that.
Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
I don't understand how things like this get approved into PEPs.
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?
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…
Earlier quoted context omitted.
Why would it be a deal breaker? uv would replace conda. And I hope it does. Conda has been such a headache for me when I've used it in the past. If the Python (particularly ML/academic community) could move on from conda it would be a great thing.
uv can’t replace conda, any more than it can replace apt or nix. Conda packages general binary packages, not just python packages. uv is just python packages.