Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv's killer feature is making ad-hoc environments easy

valatka.dev

Post reply on HN
Print view View original

151–160 of 428 posts

Re: Uv's killer feature is making ad-hoc environments easy

#151

Post by p_l »

MadnessASAP wrote: post #127
p_l wrote: post #94

Earlier quoted context omitted.

Except python builders in nixpkgs are really brain damaged because of the writers ways they inject search path which for example breaks if you try to execute a separate python interpreter assuming same library environment...

Within the holy church of Nix the sect of Python is troubled one, it can however be tamed into use via vast tomes of scripture. Sadly these times can only be written by those you have truly given their mind and body over to the almighty Nix.

It's not as bad as Common Lisp support which stinks to high heavens of someone not learning the lessons of the Common-Lisp-Controller fiasco

Re: Uv's killer feature is making ad-hoc environments easy

#152

Post by mirekrusin »

minimaxir wrote: post #47

What would be interesting is if you could do something similar for IPython/Jupyter Notebooks: while front-ends like JupyterLab and VS Code Notebooks do let you select a .venv if present in the workspace, it's annoying to have to set one up and build one for every project.

https://github.com/manzt/juv

Re: Uv's killer feature is making ad-hoc environments easy

#153

Post by fny »

mdaniel wrote: post #35
stevage wrote: post #26

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…

Because you don’t need virtualenvs or ruby_modules. You can have however many versions of the same gem installed it’s simply referenced by a gemfile, so for Ruby version X you are guaranteed one copy of gem version Y and no duplicates.

This whole installing the same dependencies a million times across different projects in Python and Node land is completely insane to me. Ruby has had the only sane package manager for years. Cargo too, but only because they copied Ruby.

Node has littered my computer with useless files. Python’s venv eat up a lot of space unnecessarily too.

Re: Uv's killer feature is making ad-hoc environments easy

#154

Post by vlovich123 »

PaulHoule wrote: post #97
whatever1 wrote: post #93

Earlier quoted context omitted.

I don’t exactly remember the situation but a user created a python module named error.py. Then in their main code they imported the said error.py but unfortunately numpy library also has an error.py. So the user was getting very funky behavior.

... it's tricky. In Java there's a cultural expectation that you name a package like package organization.dns.name.this.and.that; but real scalability in a module system requires that somebody else packages things up as package this.and.that; and you can make the system look at a particular wheel/jar/whatever and make it visible with a prefix you specify like package their.this.and.that; Programmers seem to hate rigo…

> Programmers seem to hate rigorous namespace systems though

Pretty much a nothing burger in Rust, so I disagree that items necessarily hate the concept. Maybe others haven’t done a good job with the UX?

Re: Uv's killer feature is making ad-hoc environments easy

#155

Post by benatkin »

greazy wrote: post #148
benatkin wrote: post #120

Earlier quoted context omitted.

This: > I haven't felt like it's a minor improvement on what I'm using means that this: > I'd love if we standardized on it as a community as the de facto default …probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it is…

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. This to me is unachievable. Perfection is impossible. On the the way there if the community and developers coalesced around a single tool then maybe we can start heading down the road to perfectionism.

I mean, stays out of the way for simple uses.

When I first learned Python, typing python and seeing >>> and having it evaluate what I typed as if it appeared in a file was a good experience.

Now that I use python a lot, ipython is more out of the way to me than the built-in python repl is, because it lets me focus on what I'm working on, than limitations of a tool.

Re: Uv's killer feature is making ad-hoc environments easy

#156

Post by Evidlo »

lucsky wrote: post #50
instig007 wrote: post #2

wow, they've re-invented a tiny bit of Nix, purely legend!

That you can use without having 4 PhDs. It's pretty good. You should try it sometime when your done fully ingesting algebraic topology theory or whatever the fuck Nix requires to know just to install figlet.

Try flox [0]. It's an imperative frontend for Nix that I've been using. I don't know how to use nix-shell/flakes or whatever it is they do now, but flox makes it easy to just install stuff.

[0]: https://flox.dev/

Re: Uv's killer feature is making ad-hoc environments easy

#157

Post by driggs »

NeutralCrane wrote: post #43
poincaredisk wrote: post #14

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…

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 additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. In fact, this behavior is made more difficult by tools like `uv` if or `pipx` they're trying to manage Python executables as well as dependencies.

Re: Uv's killer feature is making ad-hoc environments easy

#158

Post by greatgib »

Ridiculous post:

The author says that a normal route would be:

   - Take the proper route:

   - Create a virtual environment

   - pip install pandas

   - Activate the virtual environment

   - Run python
Basically, out of the box, when you create an virtual it is immediately activated. And you would obviously need to have it activated before doing a pip install...

In addition, in my opinion this is the thing that would sucks about UV to have different functions being tied to a single tool execution.

It is a breeze to be able to activate a venv, and be done with it, being able to run multiple times your program in one go, even with crashes, being able to install more dependencies, test it in REPL, ...

Re: Uv's killer feature is making ad-hoc environments easy

#159

Post by driggs »

Uvix wrote: post #133
driggs wrote: post #115

Earlier quoted context omitted.

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.

If you're developing a library, and you have a requirement for what's normally a transitive dependency, it should be specified as a top-level dependency.

The point is that if I'm writing a library and I specify `requests == 1.2.3`, then what are you going to do in your application if you need both my library and `requests == 1.2.4`?

This is why libraries should not use lockfiles, they should be written to safely use as wide a range of dependencies' versions as possible.

It's the developers of an application who should use a lockfile to lock transitive dependencies.

Re: Uv's killer feature is making ad-hoc environments easy

#160

Post by noitpmeder »

epistasis wrote: post #119
aeurielesn wrote: post #96

Earlier quoted context omitted.

I don't understand how things like this get approved into PEPs.

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.
Post reply on HN