4 ms·

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never

by krick 2y ago

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even bother typing pip install, PyCharm does it for me. This is of course bad practice. What I would like instead is what PHP's composer does: installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv), automatically freezes the versions, and then it is on git diff to tell me what I did last night, I'll remove a couple of lines from that file, run composer install and it will remove packages not explicitly added to my config from the environment. Does this finally get easy to achieve with uv?

8n4vidtmkvmk 2y ago
I haven't tried it, but I think so? https://docs.astral.sh/uv/concepts/projects/layout/#the-lockfile https://docs.astral.sh/uv/concepts/projects/layout/#the-lock...
wisty 2y ago
I'm not an expert, but as far as I can tell UV allows you to do this without feeling so guilty (it handles multiple versions of Python and libraries AFAIK quite well).
zahlman 2y ago
>installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv) pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.toml is meant for abstract dependencies, where an installer figures out transitively what's needed to support them and decides on exact versions to install. The current work for specifying a lockfile standard is https://peps.python.org/pep-0751/ https://peps.python.org/pep-0751/ . As someone else pointed out, uv currently already uses a proprietary lockfile, but there has been community interest in trying to standardize this - it just has been hard to find agreement on exactly what it needs to contain. (In the past there have been proposals to expand the `pyproject.toml` spec to include other information that lockfiles often contain for other languages, such as hashes and supply-chain information. Some people are extremely against this, however.) As far as I know, uv isn't going to do things like analyzing your codebase to determine that you no longer need a certain dependency that's currently in your environment and remove it (from the environment, lock file or `pyproject.toml`). You'll still be on the hook for figuring out abstractly what your project needs, and this is important if you want to share your code with others.
- krick 2y ago
  > uv isn't going to do things like analyzing your codebase Sure, that's not what I meant (unless we call pyproject.toml a part of your codebase, which it kinda is, but that's probably not what you meant). In fact, as far as I can tell from your answer, Python does move in the direction I'd like it to move, but it's unclear by how far it will miss and if how uv handles it is ergonomical. As I've said, I think PHP's composer does a very good job here, and to clarify, this is how it works. There are 2 files: composer.json (≈pyproject.toml) and composer.lock (≈ PEP751) (also json). The former is kinda editable by hand, the latter you ideally never really touch. However, for the most part composer is smart enough that it edits both files for you (with some exceptions, of course), so every time I run `composer require your/awesomelib` it 1) checks the constraints in these files 2) finds latest appropriate version of your/awesomelib (5.0.14) and all its dependencies 3) writes "your/awesomelib": "^5.0" 4) writes "your/awesomelib": "5.0.14" and all its dependencies to composer.lock (with hashsums, commit ids and such) It is a good practice to keep both inside of version control, so when I say "git diff tells me what I did last night" it means that I'll also see what I installed. If (as usual) most of it is some useless trash, I'll manually remove "your/awesomelib" from composer.json, run `composer install` and it will remove it and all its (now unneeded) dependencies. As the result, I never need to worry about bookkeeping, since composer does it for me, I just run `composer require <stuff>` and it does the rest (except for cases when <stuff> is a proprietary repo on company's gitlab and such, then I'll need slightly more manual work). That is, what I hope to see in Python one day (10 years later than every other lang did it) is declarative package management, except I don't want to have to modify pyproject.toml manually, I want my package manager do it for me, because it saves me 30 seconds of my life every time I install something. Which accumulates to a lot.
  - rochacon 2y ago
    I believe you're searching for `uv sync`: https://docs.astral.sh/uv/getting-started/features/#projects https://docs.astral.sh/uv/getting-started/features/#projects With this, you can manage the dependency list via `uv add/remove` (or the `pyproject.toml` directly), and run `uv sync` to add/remove any dependencies to the managed virtual env. Edit: adding about uv add/uv remove
mk12345 2y ago
I think it does! uv add [0] adds a dependency to your pyproject.toml, as well as your environment. If you change your pyproject.toml file manually, uv sync [1] will update your environment accordingly. [0]: https://docs.astral.sh/uv/guides/projects/#managing-dependencies https://docs.astral.sh/uv/guides/projects/#managing-dependen... [1]: https://docs.astral.sh/uv/reference/cli/#uv-sync https://docs.astral.sh/uv/reference/cli/#uv-sync
- krick 2y ago
  If I read [1] correctly, it seems it checks against lockfile, not pyproject.toml. So it seems like it won't help if I change pyproject.toml manually. Which is a big inconveniece, if so. Whatever, I think I'll try it for myself later today. It's long overdue.
  - hobofan 2y ago
    Most uv commands will (unless otherwise instructed like e.g. with --frozen) by default update your lockfile to be in sync with your pyproject.toml.

by krick 2y ago

8n4vidtmkvmk 2y ago

I haven't tried it, but I think so? https://docs.astral.sh/uv/concepts/projects/layout/#the-lockfile https://docs.astral.sh/uv/concepts/projects/layout/#the-lock...

wisty 2y ago

I'm not an expert, but as far as I can tell UV allows you to do this without feeling so guilty (it handles multiple versions of Python and libraries AFAIK quite well).

zahlman 2y ago

>installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv) pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.toml is meant for abstract dependencies, where an installer figures out transitively what's needed to support them and decides on exact versions to install. The current work for specifying a lockfile standard is https://peps.python.org/pep-0751/ https://peps.python.org/pep-0751/ . As someone else pointed out, uv currently already uses a proprietary lockfile, but there has been community interest in trying to standardize this - it just has been hard to find agreement on exactly what it needs to contain. (In the past there have been proposals to expand the `pyproject.toml` spec to include other information that lockfiles often contain for other languages, such as hashes and supply-chain information. Some people are extremely against this, however.) As far as I know, uv isn't going to do things like analyzing your codebase to determine that you no longer need a certain dependency that's currently in your environment and remove it (from the environment, lock file or `pyproject.toml`). You'll still be on the hook for figuring out abstractly what your project needs, and this is important if you want to share your code with others.

krick 2y ago
> uv isn't going to do things like analyzing your codebase Sure, that's not what I meant (unless we call pyproject.toml a part of your codebase, which it kinda is, but that's probably not what you meant). In fact, as far as I can tell from your answer, Python does move in the direction I'd like it to move, but it's unclear by how far it will miss and if how uv handles it is ergonomical. As I've said, I think PHP's composer does a very good job here, and to clarify, this is how it works. There are 2 files: composer.json (≈pyproject.toml) and composer.lock (≈ PEP751) (also json). The former is kinda editable by hand, the latter you ideally never really touch. However, for the most part composer is smart enough that it edits both files for you (with some exceptions, of course), so every time I run `composer require your/awesomelib` it 1) checks the constraints in these files 2) finds latest appropriate version of your/awesomelib (5.0.14) and all its dependencies 3) writes "your/awesomelib": "^5.0" 4) writes "your/awesomelib": "5.0.14" and all its dependencies to composer.lock (with hashsums, commit ids and such) It is a good practice to keep both inside of version control, so when I say "git diff tells me what I did last night" it means that I'll also see what I installed. If (as usual) most of it is some useless trash, I'll manually remove "your/awesomelib" from composer.json, run `composer install` and it will remove it and all its (now unneeded) dependencies. As the result, I never need to worry about bookkeeping, since composer does it for me, I just run `composer require <stuff>` and it does the rest (except for cases when <stuff> is a proprietary repo on company's gitlab and such, then I'll need slightly more manual work). That is, what I hope to see in Python one day (10 years later than every other lang did it) is declarative package management, except I don't want to have to modify pyproject.toml manually, I want my package manager do it for me, because it saves me 30 seconds of my life every time I install something. Which accumulates to a lot.
- rochacon 2y ago
  I believe you're searching for `uv sync`: https://docs.astral.sh/uv/getting-started/features/#projects https://docs.astral.sh/uv/getting-started/features/#projects With this, you can manage the dependency list via `uv add/remove` (or the `pyproject.toml` directly), and run `uv sync` to add/remove any dependencies to the managed virtual env. Edit: adding about uv add/uv remove

mk12345 2y ago

I think it does! uv add [0] adds a dependency to your pyproject.toml, as well as your environment. If you change your pyproject.toml file manually, uv sync [1] will update your environment accordingly. [0]: https://docs.astral.sh/uv/guides/projects/#managing-dependencies https://docs.astral.sh/uv/guides/projects/#managing-dependen... [1]: https://docs.astral.sh/uv/reference/cli/#uv-sync https://docs.astral.sh/uv/reference/cli/#uv-sync

krick 2y ago
If I read [1] correctly, it seems it checks against lockfile, not pyproject.toml. So it seems like it won't help if I change pyproject.toml manually. Which is a big inconveniece, if so. Whatever, I think I'll try it for myself later today. It's long overdue.
- hobofan 2y ago
  Most uv commands will (unless otherwise instructed like e.g. with --frozen) by default update your lockfile to be in sync with your pyproject.toml.