8 ms·

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every pr

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see uv doesn't make this easy.

taftster 1y ago
You can't just create yourself an "everything" environment with UV and then experiment with it? Honest question. I think you're basically suggesting that you'd have a VM or something that has system-high packages already preinstalled and then use UV on top of it?
- BrenBarn 1y ago
  If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/ https://docs.astral.sh/uv/getting-started/features/ I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools). You can use the `uv venv` and the `uv pip` stuff to create an environment and install stuff into it, but this isn't really different from normal venvs. And in particular it doesn't give me much benefit over conda/mamba. I get that the project-based workflow is what a lot of people want, and I might even want it sometimes, but I don't want to be forced into foregrounding the project.
  - jcattle 1y ago
    > And in particular it doesn't give me much benefit over conda/mamba. How about the advantage of not taking an entire lunch break to resolve the environment every time you go to install a new library? That was the biggest sticking point with conda/mamba for me. It's been a few years since I last used them but in particular with geospatial packages I would often run into issues.
    - greazy 1y ago
      libmamba solved this year's ago. The dep solver is now much faster.
    - blactuary 1y ago
      This is not the case anymore. With libmamba I've never waited more than a few minutes for resolving dependencies and installing. uv is faster for sure, but speed is no longer a big problem with conda
  - deleted 1y ago
    [deleted]
  - philipallstar 1y ago
    > I don't want to be forced into foregrounding the project. The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project, run uv install and get working. It's the death of "works on my machine" and "well it'll take them a couple of weeks to properly get up and running".
    - BrenBarn 1y ago
      Sure, that's fine. I'm saying I just won't get to that stage until later.
      - dragonwriter 1y ago
        A “project" is largely a way of storing the definition of the state of a environment in a config file (pyproject.toml). It does a bit more, but you can basically ignore that initially. It takes a couple of seconds to setup, and then you just use uv add instead of (uv) pip install to add things to the environment, and the project file is kept in sync with the state of the environment. I'm not really understanding what it is for the workflow you describe that you expect a tool to do that uv isn’t providing?
    - neves 1y ago
      Just professional software engineering practices.
    - zahlman 1y ago
      > The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project I know this might be a strange idea on HN, but tons of people writing code in Python, who need access to PyPI packages to do what they're doing, have no intention whatsoever of providing a clonable project to others, or sharing it in any other way, or indeed expecting anyone else on the planet to run the code.
  - fouc 1y ago
    I assume if you stick a .venv in your home directory it'll essentially be available globally as you desired.. and overridden in project specific .venv or similar
- zelphirkalt 1y ago
  You can, but an "everything environment" is rarely to be recommended. How to do it: Make uv use the --active environment to install things. Before using uv, activate that environment.
- quietbritishjim 1y ago
  I think that user (like me until finding out just now) didn't know that you could make ad-hoc virtual environments with uv, and that instead you would have to make a directory with a pyproject.toml and install things into it by adding to that pyproject.toml
trymas 1y ago
You can setup uv inside your script, without a project. Example: https://treyhunner.com/2024/12/lazy-self-installing-python-scripts-with-uv/ https://treyhunner.com/2024/12/lazy-self-installing-python-s...
- BrenBarn 1y ago
  I'm not talking about wanting single-file scripts, but about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.
  - jrvarela56 1y ago
    I have a directory called workspace where there’s a projects directory and the main area is for messing around. Just setup workspace once as a project.
    - BrenBarn 1y ago
      But I don't want the sandbox linked in any way to a directory. I just want to be able to use it from anywhere. (This is what I can do with conda.)
      - csnweb 1y ago
        You can activate the uv venv from anywhere just fine, just do source path_to_sandbox/.venv/bin/activate. Probably makes sense to define a shortcut for that like activate sandbox. Your conda env is also linked to a directory, it’s just a hidden one, you can also create the uv obe somewhere hidden. But I get it to some extent conda has this large prefilled envs with a lot of stuff in it already that work together. Still if you then end up needing anything else you wait ages for the install. I find conda so unbearable by now that I voluntarily switch every conda thing I have left over to uv the second I need to touch the conda env.
      - zelphirkalt 1y ago
        A shell alias that activates workspace/sandbox?
tlarkworthy 1y ago
It unblocks that workflow, that's why it's so great. You can have a single script with inline dependencies that are auto installed on execution. That can expand to importing other files, but there is very little setup tax to get started with a script and it does not block expansion.
- BrenBarn 1y ago
  It's not about single-file scripts, it's about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.
  - blactuary 1y ago
    This is a divide among different Python devs it seems. A lot of people are running scripts, which I will do eventually, but I spend a ton of time in a REPL experimenting and testing.
    - BrenBarn 1y ago
      Yeah, it's this experiment-first workflow that's not so well supported.
9dev 1y ago
Interesting. I never start working on something without a rough idea of what I am working on, be that just researching something or a program; and uv makes it extremely easy to create a folder, and make it a project. Could it be that you’re just used to separate environments causing so much pain that you avoid it unless you’re serious about what you’re doing?
- fastasucan 1y ago
  If they are like me, they are just exploring different data, ideas and stuff - maybe without knowing/having descided if it will be a project. Many times it nice to use Python as a tool explore some data.
RobinL 1y ago
https://docs.astral.sh/uv/concepts/projects/init/#creating-a-minimal-project https://docs.astral.sh/uv/concepts/projects/init/#creating-a... I use the 'bare' option for this
atoav 1y ago
Go ahead and do that then. uv is not preventing you from putting 10 projects within one folder. It is still benefitial to not install stuff system wide, since this makes it easy to forget which stuff you already have installed and which is a missing dependency. Keeping track of dependencies is kind part of a programers work, so as long as you're writing these things mostly for yourself do whatever you like. And I say that as someone who treats everything like a project that I will forget about in 3 days and need to deploy on some server a year later.
Uehreka 1y ago
This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it wherever I need to without breaking anything, needing to reset my PATH or needing to call `source` inside a Dockerfile (oh lord). Many people complain about Node and npm, but as someone who works on a million things, Node/npm is never something I need to think about. Python/pip though… Every time I need to containerize or setup a Python project for some arbitrary task, there’s always an issue with “Your Linux distro doesn’t support that version of Python anymore”, forcing me to use a newer version than the project wants and triggering an avalanche of new “you really shouldn’t install packages globally” messages, demanding new —yes-destroy-my-computer-dangerously-and-step-on-my-face-daddy flags and crashing my automated scripts from last year. And then there’s Conda, which has all of these problems and is also closed source (I think?) and has a EULA, which makes it an even bigger pain to automate cleanly (And yes I know about mamba, and miniconda, but the default tool everyone uses should be the one that’s easy to work with). And yes, I know that if I was a full-time Python dev there’s a “better way” that I’d know about. But I think a desirable quality for languages/ecosystems is the ability for an outsider to drop in with general Linux/Docker knowledge and be able to package things up in a sometimes unusual way. And until uv, Python absolutely failed in this regard.
- jampekka 1y ago
  Having a directory like node_modules containing the dependencies is such an obviously good choice, it's sad how Python steering council actively resists this with what I find odd arguments. I think a lot of the decades old farce of Python package management would have been solved by this. https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/ https://discuss.python.org/t/pep-582-python-local-packages-directory/963/431 https://discuss.python.org/t/pep-582-python-local-packages-d...
  - zelphirkalt 1y ago
    It's literally what a venv does and it is very widespread to just make a venv per project, just like you are creating a node_modules per project.
gempir 1y ago
This is easier to do with uv than it is with pip. You can create venvs wherever you please and then just install stuff into them. Nobody forces the project onto you, at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system.
- zelphirkalt 1y ago
  Way to go to create non-reproducible results. Basically, nothing production ready is rolling out of that one.
  - gempir 1y ago
    This is what the OP wanted. I don't agree to do it this way. At work for us we use uv pip freeze to generate a more strict requirements file.
    - zelphirkalt 1y ago
      What I was referring to is: > [...] at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system. Unless your `python_requirements.txt` also carries checksums, like uv's lock files or poetry's lock files, that is. Though of course things get spicy and non-reproducible again, if you have then multiple projects/services, each with their own `python_requirements.txt`, all installing into that same global venv ...
lurking_swe 1y ago
Serious question - what’s stopping you from having 1 large project called “sandbox”?
northzen 1y ago
Use pixi (whici is build with uv) and use its "global". It should solve what you wanted to solve: https://pixi.sh/dev/global_tools/introduction/ https://pixi.sh/dev/global_tools/introduction/
matsemann 1y ago
What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.
- brap 1y ago
  My sentiment coming to Python after getting used to the DX of Node https://uploads.dailydot.com/2024/04/damn-bitch-you-live-like-this-.jpg https://uploads.dailydot.com/2024/04/damn-bitch-you-live-lik...
  - abenga 1y ago
    My exact reaction when I visit front-end-land. It always surprises me that you can't just leave a project alone for some time, get back to it and continue where you left off. There are always a couple of days of getting the thing to work again, then figuring out how everyone is doing things now, because apparently that has to change every few months.
    - brap 1y ago
      While I don’t do frontend and don’t want to defend that mess, I think that locking a specific version for each dependency would solve this
      - abenga 1y ago
        Uv allows you to lock versions too. And creates a .venv inside the project which, I guess, is similar to the node_modules directory.
        brap 1y ago
        For sure, I was referring to the state of python before uv. Specifically projects not being self-contained, easily portable, etc
jdranczewski 1y ago
I agree that having a reliable main environment for quick experiments is great! On Windows I just use the main Python installation as a global environment, since no system stuff depends on it, on Linux I tend to create a "main" environment in the home directory. Then I can still have per-project environments as needed (say with uv), for example for stuff that I need to deploy to the VPS. Note that I'm mostly in the research/hobby environments - I think this approach (and Python in general, re: some other discussions here about the language) works really well, especially for the latter, but the closer you get to "serious" work, the more sense the project environment approach makes of course
- zelphirkalt 1y ago
  Especially in research the project environment approach makes sense, where results don't mean much without reproducibility.
vietvu 1y ago
You can just `uv venv`? Or even uvx?
dimatura 1y ago
Whenever I feel like doing that I just use "uv pip" and pretty much do the same things I'd do when using pip to messily install things in a typical virtual environment.
unglaublich 1y ago
https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... or `uvx --with my-package ipython`
zelphirkalt 1y ago
Neither of the tools (uv, poetry) makes it the default, and the poetry designers/developers are kinda ignorant about this, but it can be done.
forrestthewoods 1y ago
> I don't want a separate environment for every project That is exactly 100% what I demand. Projects should be - must be - completely isolated from one another. Quite frankly anything else seems utterly insane to me.
lvl155 1y ago
You set up a template project folder. In the script you can just add a uv command. In the age of Claude Code and Codex, creating a sandbox/container should be step one.
codeptualize 1y ago
But then you don't need uv. The pain point uv solves is projects. Different projects with different dependencies (even the same but different versions), multiple people, teams, and environments trying to run the same code. That gets problematic if environments go out of sync, or you need different versions of python or dependencies. So you are right, you probably won't benefit a lot if you just have one big environment and that works for you, but once you pull things in a project, uv is the best tool out there atm. You could also just create a starter project that has all the things you want, and then later on pull it out, that would be the same thing.
BiteCode_dev 1y ago
It doesn't. uv has a script mode, a temp env mode, and a way to superimpose a temp env on top of an existing env. See: https://www.bitecode.dev/p/uv-tricks https://www.bitecode.dev/p/uv-tricks That's one of the selling point of the tool: you don't need a project, you don't need activate anything, you don't even need to keep code around. Yesterday I wanted to mess around with logoru in ipython. I just ran `uvx --with loguru ipython` and I was ready to go. Not even a code file to open. Nothing to explicitly install nor to clean up. For a tool that is that fantastic and create such enthusiasm, I'm always surprise of how little of its feature people know about. It can do crazy stuff.
quietbritishjim 1y ago
I have the same feeling, so I just looked it up and actually uv does support exactly that mode. It works the same as venv and pip but you just prefix a bunch of commands with "uv". Create a new virtual environment fooenv: uv venv fooenv Activate virtual environment on Windows (yes I'm sorry that's what I'm currently typing on!): .\fooenv\Scripts\activate Run some environment commands: uv pip install numpy uv pip freeze uv pip uninstall numpy If you run python now, it will be in this virtual environment. You can deactivate it with: deactivate Admittedly, there doesn't seem to be much benefit compared to traditional venv/pip for this use case. This is covered in the section of the docs titled "The pip interface": https://docs.astral.sh/uv/pip/ https://docs.astral.sh/uv/pip/
- zahlman 1y ago
  > Admittedly, there doesn't seem to be much benefit compared to traditional venv/pip for this use case. Performance?
blactuary 1y ago
This is me exactly. I have a default dev environment, and a couple for experimenting with new versions of various packages, I don't need or want "projects" most of the time
- neves 1y ago
  This is nice just for playing and exploring alone. It is a nightmare if you need reproducibility, to send something for production, or event to share your work with someone. Maybe even to come back to your project an year later. uv.lock is a bless

taftster 1y ago

You can't just create yourself an "everything" environment with UV and then experiment with it? Honest question. I think you're basically suggesting that you'd have a VM or something that has system-high packages already preinstalled and then use UV on top of it?

BrenBarn 1y ago
If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/ https://docs.astral.sh/uv/getting-started/features/ I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools). You can use the `uv venv` and the `uv pip` stuff to create an environment and install stuff into it, but this isn't really different from normal venvs. And in particular it doesn't give me much benefit over conda/mamba. I get that the project-based workflow is what a lot of people want, and I might even want it sometimes, but I don't want to be forced into foregrounding the project.
- jcattle 1y ago
  > And in particular it doesn't give me much benefit over conda/mamba. How about the advantage of not taking an entire lunch break to resolve the environment every time you go to install a new library? That was the biggest sticking point with conda/mamba for me. It's been a few years since I last used them but in particular with geospatial packages I would often run into issues.
  - greazy 1y ago
    libmamba solved this year's ago. The dep solver is now much faster.
  - blactuary 1y ago
    This is not the case anymore. With libmamba I've never waited more than a few minutes for resolving dependencies and installing. uv is faster for sure, but speed is no longer a big problem with conda
- deleted 1y ago
  [deleted]
- philipallstar 1y ago
  > I don't want to be forced into foregrounding the project. The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project, run uv install and get working. It's the death of "works on my machine" and "well it'll take them a couple of weeks to properly get up and running".
  - BrenBarn 1y ago
    Sure, that's fine. I'm saying I just won't get to that stage until later.
    - dragonwriter 1y ago
      A “project" is largely a way of storing the definition of the state of a environment in a config file (pyproject.toml). It does a bit more, but you can basically ignore that initially. It takes a couple of seconds to setup, and then you just use uv add instead of (uv) pip install to add things to the environment, and the project file is kept in sync with the state of the environment. I'm not really understanding what it is for the workflow you describe that you expect a tool to do that uv isn’t providing?
  - neves 1y ago
    Just professional software engineering practices.
  - zahlman 1y ago
    > The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project I know this might be a strange idea on HN, but tons of people writing code in Python, who need access to PyPI packages to do what they're doing, have no intention whatsoever of providing a clonable project to others, or sharing it in any other way, or indeed expecting anyone else on the planet to run the code.
- fouc 1y ago
  I assume if you stick a .venv in your home directory it'll essentially be available globally as you desired.. and overridden in project specific .venv or similar
zelphirkalt 1y ago
You can, but an "everything environment" is rarely to be recommended. How to do it: Make uv use the --active environment to install things. Before using uv, activate that environment.
quietbritishjim 1y ago
I think that user (like me until finding out just now) didn't know that you could make ad-hoc virtual environments with uv, and that instead you would have to make a directory with a pyproject.toml and install things into it by adding to that pyproject.toml

trymas 1y ago

You can setup uv inside your script, without a project. Example: https://treyhunner.com/2024/12/lazy-self-installing-python-scripts-with-uv/ https://treyhunner.com/2024/12/lazy-self-installing-python-s...

BrenBarn 1y ago
I'm not talking about wanting single-file scripts, but about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.
- jrvarela56 1y ago
  I have a directory called workspace where there’s a projects directory and the main area is for messing around. Just setup workspace once as a project.
  - BrenBarn 1y ago
    But I don't want the sandbox linked in any way to a directory. I just want to be able to use it from anywhere. (This is what I can do with conda.)
    - csnweb 1y ago
      You can activate the uv venv from anywhere just fine, just do source path_to_sandbox/.venv/bin/activate. Probably makes sense to define a shortcut for that like activate sandbox. Your conda env is also linked to a directory, it’s just a hidden one, you can also create the uv obe somewhere hidden. But I get it to some extent conda has this large prefilled envs with a lot of stuff in it already that work together. Still if you then end up needing anything else you wait ages for the install. I find conda so unbearable by now that I voluntarily switch every conda thing I have left over to uv the second I need to touch the conda env.
    - zelphirkalt 1y ago
      A shell alias that activates workspace/sandbox?

tlarkworthy 1y ago

It unblocks that workflow, that's why it's so great. You can have a single script with inline dependencies that are auto installed on execution. That can expand to importing other files, but there is very little setup tax to get started with a script and it does not block expansion.

BrenBarn 1y ago
It's not about single-file scripts, it's about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.
- blactuary 1y ago
  This is a divide among different Python devs it seems. A lot of people are running scripts, which I will do eventually, but I spend a ton of time in a REPL experimenting and testing.
  - BrenBarn 1y ago
    Yeah, it's this experiment-first workflow that's not so well supported.

9dev 1y ago

Interesting. I never start working on something without a rough idea of what I am working on, be that just researching something or a program; and uv makes it extremely easy to create a folder, and make it a project. Could it be that you’re just used to separate environments causing so much pain that you avoid it unless you’re serious about what you’re doing?

fastasucan 1y ago
If they are like me, they are just exploring different data, ideas and stuff - maybe without knowing/having descided if it will be a project. Many times it nice to use Python as a tool explore some data.

RobinL 1y ago

https://docs.astral.sh/uv/concepts/projects/init/#creating-a-minimal-project https://docs.astral.sh/uv/concepts/projects/init/#creating-a... I use the 'bare' option for this

atoav 1y ago

Go ahead and do that then. uv is not preventing you from putting 10 projects within one folder. It is still benefitial to not install stuff system wide, since this makes it easy to forget which stuff you already have installed and which is a missing dependency. Keeping track of dependencies is kind part of a programers work, so as long as you're writing these things mostly for yourself do whatever you like. And I say that as someone who treats everything like a project that I will forget about in 3 days and need to deploy on some server a year later.

Uehreka 1y ago

This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it wherever I need to without breaking anything, needing to reset my PATH or needing to call `source` inside a Dockerfile (oh lord). Many people complain about Node and npm, but as someone who works on a million things, Node/npm is never something I need to think about. Python/pip though… Every time I need to containerize or setup a Python project for some arbitrary task, there’s always an issue with “Your Linux distro doesn’t support that version of Python anymore”, forcing me to use a newer version than the project wants and triggering an avalanche of new “you really shouldn’t install packages globally” messages, demanding new —yes-destroy-my-computer-dangerously-and-step-on-my-face-daddy flags and crashing my automated scripts from last year. And then there’s Conda, which has all of these problems and is also closed source (I think?) and has a EULA, which makes it an even bigger pain to automate cleanly (And yes I know about mamba, and miniconda, but the default tool everyone uses should be the one that’s easy to work with). And yes, I know that if I was a full-time Python dev there’s a “better way” that I’d know about. But I think a desirable quality for languages/ecosystems is the ability for an outsider to drop in with general Linux/Docker knowledge and be able to package things up in a sometimes unusual way. And until uv, Python absolutely failed in this regard.

jampekka 1y ago
Having a directory like node_modules containing the dependencies is such an obviously good choice, it's sad how Python steering council actively resists this with what I find odd arguments. I think a lot of the decades old farce of Python package management would have been solved by this. https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/ https://discuss.python.org/t/pep-582-python-local-packages-directory/963/431 https://discuss.python.org/t/pep-582-python-local-packages-d...
- zelphirkalt 1y ago
  It's literally what a venv does and it is very widespread to just make a venv per project, just like you are creating a node_modules per project.

gempir 1y ago

This is easier to do with uv than it is with pip. You can create venvs wherever you please and then just install stuff into them. Nobody forces the project onto you, at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system.

zelphirkalt 1y ago
Way to go to create non-reproducible results. Basically, nothing production ready is rolling out of that one.
- gempir 1y ago
  This is what the OP wanted. I don't agree to do it this way. At work for us we use uv pip freeze to generate a more strict requirements file.
  - zelphirkalt 1y ago
    What I was referring to is: > [...] at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system. Unless your `python_requirements.txt` also carries checksums, like uv's lock files or poetry's lock files, that is. Though of course things get spicy and non-reproducible again, if you have then multiple projects/services, each with their own `python_requirements.txt`, all installing into that same global venv ...

lurking_swe 1y ago

Serious question - what’s stopping you from having 1 large project called “sandbox”?

northzen 1y ago

Use pixi (whici is build with uv) and use its "global". It should solve what you wanted to solve: https://pixi.sh/dev/global_tools/introduction/ https://pixi.sh/dev/global_tools/introduction/

matsemann 1y ago

What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.

brap 1y ago
My sentiment coming to Python after getting used to the DX of Node https://uploads.dailydot.com/2024/04/damn-bitch-you-live-like-this-.jpg https://uploads.dailydot.com/2024/04/damn-bitch-you-live-lik...
- abenga 1y ago
  My exact reaction when I visit front-end-land. It always surprises me that you can't just leave a project alone for some time, get back to it and continue where you left off. There are always a couple of days of getting the thing to work again, then figuring out how everyone is doing things now, because apparently that has to change every few months.
  - brap 1y ago
    While I don’t do frontend and don’t want to defend that mess, I think that locking a specific version for each dependency would solve this
    - abenga 1y ago
      Uv allows you to lock versions too. And creates a .venv inside the project which, I guess, is similar to the node_modules directory.
      - brap 1y ago
        For sure, I was referring to the state of python before uv. Specifically projects not being self-contained, easily portable, etc

jdranczewski 1y ago

I agree that having a reliable main environment for quick experiments is great! On Windows I just use the main Python installation as a global environment, since no system stuff depends on it, on Linux I tend to create a "main" environment in the home directory. Then I can still have per-project environments as needed (say with uv), for example for stuff that I need to deploy to the VPS. Note that I'm mostly in the research/hobby environments - I think this approach (and Python in general, re: some other discussions here about the language) works really well, especially for the latter, but the closer you get to "serious" work, the more sense the project environment approach makes of course

zelphirkalt 1y ago
Especially in research the project environment approach makes sense, where results don't mean much without reproducibility.

vietvu 1y ago

You can just `uv venv`? Or even uvx?

dimatura 1y ago

Whenever I feel like doing that I just use "uv pip" and pretty much do the same things I'd do when using pip to messily install things in a typical virtual environment.

unglaublich 1y ago

https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... or `uvx --with my-package ipython`

zelphirkalt 1y ago

Neither of the tools (uv, poetry) makes it the default, and the poetry designers/developers are kinda ignorant about this, but it can be done.

forrestthewoods 1y ago

> I don't want a separate environment for every project That is exactly 100% what I demand. Projects should be - must be - completely isolated from one another. Quite frankly anything else seems utterly insane to me.

lvl155 1y ago

You set up a template project folder. In the script you can just add a uv command. In the age of Claude Code and Codex, creating a sandbox/container should be step one.

codeptualize 1y ago

But then you don't need uv. The pain point uv solves is projects. Different projects with different dependencies (even the same but different versions), multiple people, teams, and environments trying to run the same code. That gets problematic if environments go out of sync, or you need different versions of python or dependencies. So you are right, you probably won't benefit a lot if you just have one big environment and that works for you, but once you pull things in a project, uv is the best tool out there atm. You could also just create a starter project that has all the things you want, and then later on pull it out, that would be the same thing.

BiteCode_dev 1y ago

It doesn't. uv has a script mode, a temp env mode, and a way to superimpose a temp env on top of an existing env. See: https://www.bitecode.dev/p/uv-tricks https://www.bitecode.dev/p/uv-tricks That's one of the selling point of the tool: you don't need a project, you don't need activate anything, you don't even need to keep code around. Yesterday I wanted to mess around with logoru in ipython. I just ran `uvx --with loguru ipython` and I was ready to go. Not even a code file to open. Nothing to explicitly install nor to clean up. For a tool that is that fantastic and create such enthusiasm, I'm always surprise of how little of its feature people know about. It can do crazy stuff.

quietbritishjim 1y ago

I have the same feeling, so I just looked it up and actually uv does support exactly that mode. It works the same as venv and pip but you just prefix a bunch of commands with "uv". Create a new virtual environment fooenv: uv venv fooenv Activate virtual environment on Windows (yes I'm sorry that's what I'm currently typing on!): .\fooenv\Scripts\activate Run some environment commands: uv pip install numpy uv pip freeze uv pip uninstall numpy If you run python now, it will be in this virtual environment. You can deactivate it with: deactivate Admittedly, there doesn't seem to be much benefit compared to traditional venv/pip for this use case. This is covered in the section of the docs titled "The pip interface": https://docs.astral.sh/uv/pip/ https://docs.astral.sh/uv/pip/

zahlman 1y ago
> Admittedly, there doesn't seem to be much benefit compared to traditional venv/pip for this use case. Performance?

blactuary 1y ago

This is me exactly. I have a default dev environment, and a couple for experimenting with new versions of various packages, I don't need or want "projects" most of the time

neves 1y ago
This is nice just for playing and exploring alone. It is a nightmare if you need reproducibility, to send something for production, or event to share your work with someone. Maybe even to come back to your project an year later. uv.lock is a bless