4 ms·

been in the python game a long time and i've seen so many tools in this space come and go over the years. i still rely on good ol pip and have had no issues. th

been in the python game a long time and i've seen so many tools in this space come and go over the years. i still rely on good ol pip and have had no issues. that said, we utilize mypy and ruff, and have moved to pyproject etc to remotely keep up with the times.

jitl 7mo ago
uv solved it, it will be the only tool people use in 2 more years. if you’re a python shop / expert then you can do pip etc but uv turned incidental python + deps from a huge PITA for the rest of us, to It Just Works simplicity on the same level or better than Golang.
- 1718627440 7mo ago
  I don't want software on my computer, that just downloads and installs random stuff. This is the job of the OS in particular the package manager.
  - mirekrusin 7mo ago
    Then don't use it?
  - QuantumNomad_ 7mo ago
    What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older. And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.
    - 1718627440 7mo ago
      > What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older. I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all. > And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has. This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.
  - zbentley 7mo ago
    Do you not use non-OS package managers? If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?
    - 1718627440 7mo ago
      > Do you not use non-OS package managers? Mostly no, sometimes I give up and still use pip as a separate user. > If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool I haven't felt the need to use Go, the only Java software I use is in the OS repo. I don't want to use JS software for other reasons. This is one of the reasons why I don't like Rust rewrites. Python dependencies are very often in the OS repo. If there is anything else, I compile it from source and I curse when software doesn't use or adheres to the standard of the GNU build system.
      - maleldil 7mo ago
        I hope you understand you are part of a very, very small minority.
      - zbentley 7mo ago
        Thanks for explaining your workflow. It seems predictable, but like it really locks you into one of the few (albeit popular) programming languages that has many/most of its development libraries repackaged by your OS. There are plenty of very popular languages that don't offer that at all. Go and Rust, specifically, seem a bit odd to be allergic to. Their "package managers" are largely downloading sources into your code repository, not downloading/installing truly arbitrary stuff. How is that different from your (presumably "wget the file into my repo or include path") workflow for depending on a header-only C library from the internet which your OS doesn't repackage? I understand if your resistance to those platforms is because of how much source code things download, but that still seems qualitatively different to me from "npm install can do god-knows-what to my workstation" or "pip install can install packages that shadow system-wide trusted ones".
    - 7mo ago
  - maccard 7mo ago
    Do you use pip?
  - wiseowise 7mo ago
    Don't worry, gramps, pip won't trigger your tinfoil hat.
  - dotancohen 7mo ago
    In general I agree with you. But not for software dev packages. The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.
  - jitl 7mo ago
    You're welcome to live in the 90s dark ages, I feel this attitude and the shape of the old linux distros like Debian that laboriously re-package years-old software have been one of the biggest failures of open source and squandered untold hours of human effort. It's a model that works okay for generic infrastructure but requires far too much labor and moves far too slowly with quite a poor experience for end users and developers. Why else would all modern software development (going back to perl's cpan package manager in 1995) route around it?
  - nimchimpsky 7mo ago
    [dead]
  - ghshephard 7mo ago
    I very much appreciate the sentiment - and agree that random crap (particularly some of the insane dependency chains that you get from NPM, but also Rust) in which you go to install a simple (at least you believe) package - and the Rust/NPM manager downloads several hundred dependencies. But the problem with only using the OS package manager is that you then lock yourself out of the entire ecosystem of node, python, rust packages that have never been migrated to whatever operating system you are using - which might be very significant. How do you feel about Nix? It feels like this is a nice half-way measure between reliable/reproducible builds, but without all of the Free For all where you are downloading who-knows-what-from-where onto your OS?
- pdntspa 7mo ago
  Then can they please figure out some way of invoking it that doesnt require prefixing everything with 'uv'
  - tomrod 7mo ago
    alias in ~/.zshrc?
  - cjp 7mo ago
    direnv, .envrc, "layout uv" https://github.com/direnv/direnv/wiki/Python#uv https://github.com/direnv/direnv/wiki/Python#uv
  - malcolmgreaves 7mo ago
    uv run bash/zsh/your shell of choice
  - maleldil 7mo ago
    You can source the virtualenv like normal.
  - arw0n 7mo ago
    For any command, you can create an 'alias' in your shell config. That way you can get rid of the prefix.
  - ghshephard 7mo ago
    Solved with direnv. Also - in my .bashrc in all of my (many) clients: $ type uvi uvl uvv uvi is a function uvi () { uv pip install $@ } uvl is a function uvl () { uv pip list } uvv is a function uvv () { uv venv; cat > .envrc <<EOF source .venv/bin/activate EOF direnv allow }
  - duskdozer 6mo ago
    That would defeat the purpose of creating and expanding their brand.
tomrod 7mo ago
Geospatial tends to be the Achilles heel for python projects for me. Fiona is a wiley beast of a package, and GDAL too. Conda helped some but was always so slow. Pip almost uniformly fails in this area for me.
- crimsoneer 7mo ago
  Yup, the fact UV just installed geopandas out of the box with no issues blew my mind.

jitl 7mo ago

uv solved it, it will be the only tool people use in 2 more years. if you’re a python shop / expert then you can do pip etc but uv turned incidental python + deps from a huge PITA for the rest of us, to It Just Works simplicity on the same level or better than Golang.

1718627440 7mo ago
I don't want software on my computer, that just downloads and installs random stuff. This is the job of the OS in particular the package manager.
- mirekrusin 7mo ago
  Then don't use it?
- QuantumNomad_ 7mo ago
  What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older. And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.
  - 1718627440 7mo ago
    > What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older. I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all. > And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has. This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.
- zbentley 7mo ago
  Do you not use non-OS package managers? If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?
  - 1718627440 7mo ago
    > Do you not use non-OS package managers? Mostly no, sometimes I give up and still use pip as a separate user. > If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool I haven't felt the need to use Go, the only Java software I use is in the OS repo. I don't want to use JS software for other reasons. This is one of the reasons why I don't like Rust rewrites. Python dependencies are very often in the OS repo. If there is anything else, I compile it from source and I curse when software doesn't use or adheres to the standard of the GNU build system.
    - maleldil 7mo ago
      I hope you understand you are part of a very, very small minority.
    - zbentley 7mo ago
      Thanks for explaining your workflow. It seems predictable, but like it really locks you into one of the few (albeit popular) programming languages that has many/most of its development libraries repackaged by your OS. There are plenty of very popular languages that don't offer that at all. Go and Rust, specifically, seem a bit odd to be allergic to. Their "package managers" are largely downloading sources into your code repository, not downloading/installing truly arbitrary stuff. How is that different from your (presumably "wget the file into my repo or include path") workflow for depending on a header-only C library from the internet which your OS doesn't repackage? I understand if your resistance to those platforms is because of how much source code things download, but that still seems qualitatively different to me from "npm install can do god-knows-what to my workstation" or "pip install can install packages that shadow system-wide trusted ones".
  - 7mo ago
- maccard 7mo ago
  Do you use pip?
- wiseowise 7mo ago
  Don't worry, gramps, pip won't trigger your tinfoil hat.
- dotancohen 7mo ago
  In general I agree with you. But not for software dev packages. The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.
- jitl 7mo ago
  You're welcome to live in the 90s dark ages, I feel this attitude and the shape of the old linux distros like Debian that laboriously re-package years-old software have been one of the biggest failures of open source and squandered untold hours of human effort. It's a model that works okay for generic infrastructure but requires far too much labor and moves far too slowly with quite a poor experience for end users and developers. Why else would all modern software development (going back to perl's cpan package manager in 1995) route around it?
- nimchimpsky 7mo ago
  [dead]
- ghshephard 7mo ago
  I very much appreciate the sentiment - and agree that random crap (particularly some of the insane dependency chains that you get from NPM, but also Rust) in which you go to install a simple (at least you believe) package - and the Rust/NPM manager downloads several hundred dependencies. But the problem with only using the OS package manager is that you then lock yourself out of the entire ecosystem of node, python, rust packages that have never been migrated to whatever operating system you are using - which might be very significant. How do you feel about Nix? It feels like this is a nice half-way measure between reliable/reproducible builds, but without all of the Free For all where you are downloading who-knows-what-from-where onto your OS?
pdntspa 7mo ago
Then can they please figure out some way of invoking it that doesnt require prefixing everything with 'uv'
- tomrod 7mo ago
  alias in ~/.zshrc?
- cjp 7mo ago
  direnv, .envrc, "layout uv" https://github.com/direnv/direnv/wiki/Python#uv https://github.com/direnv/direnv/wiki/Python#uv
- malcolmgreaves 7mo ago
  uv run bash/zsh/your shell of choice
- maleldil 7mo ago
  You can source the virtualenv like normal.
- arw0n 7mo ago
  For any command, you can create an 'alias' in your shell config. That way you can get rid of the prefix.
- ghshephard 7mo ago
  Solved with direnv. Also - in my .bashrc in all of my (many) clients: $ type uvi uvl uvv uvi is a function uvi () { uv pip install $@ } uvl is a function uvl () { uv pip list } uvv is a function uvv () { uv venv; cat > .envrc <<EOF source .venv/bin/activate EOF direnv allow }
- duskdozer 6mo ago
  That would defeat the purpose of creating and expanding their brand.

tomrod 7mo ago

Geospatial tends to be the Achilles heel for python projects for me. Fiona is a wiley beast of a package, and GDAL too. Conda helped some but was always so slow. Pip almost uniformly fails in this area for me.

crimsoneer 7mo ago
Yup, the fact UV just installed geopandas out of the box with no issues blew my mind.