7 ms·

> Make sure you don't have anything else relying on Python because they will probably never work again. This is why when I see some clever open source tool dis

> Make sure you don't have anything else relying on Python because they will probably never work again. This is why when I see some clever open source tool discussed on HN and I go to the repo and see it's written in Python I close the browser window and pretend I never saw it. Yes I know there are ways to protect yourself when using Python in much the same way that lead-lined glove boxes protect you when working with plutonium, but I can never remember the proper CLI incantation to make the lead-lined glove box appear.

wtallis 1y ago
These days, if I'm feeling generous I'll spend a minute or two to see if I can get a promising Python tool to install with uv. If it's not going to easily submit to a `uv tool install`, then I move on and forget about it.
ecshafer 1y ago
UV has gone a long way to fix that issue with python.
- zahlman 1y ago
  uv has not really done that much. It's all been possible, and usually about as ergonomically. It's just opinionated in a way that people currently seem to like, and fast primarily due to good internal design (not because it's written in rocket emoji Rust sparkle emoji, although that certainly is a net positive to performance).
  - lmm 1y ago
    UV hasn't done anything except for all the parts that matter. (And while there are compelling arguments that Rust has nothing to do with it, the correlation is pretty strong)
    - noitpmeder 1y ago
      UV has provided easy solutions for engineers that are easily frustrated by a lack of easy solutions. There's nothing wrong with easy solutions, but any python engineer worth their salt has long since solved and moved on from the issues that UV claims to solve. I believe UV provides value, even significant value, to lite python users, but for those working with python day in and day out, maybe you're using a new tool, but life has not changed significantly for the better. Or you just sucked and didn't reach for any of the perfectly usable solutions to all of these problems that existed before UV showed up.
      - wtallis 1y ago
        uv provides a breadth of functionality that no single tool has before, and that no simple, easy combination of tools has before. For developers, it replaces poetry with something much faster and more reliable, and replaces pipenv. For end users, it replaces pipx and pyenv, and pretty much replaces pip itself (which no longer wants to be used by end users). And most importantly, uv relieves you of having to remember which of the preceding tools are suitable for which use cases.
        zahlman 1y ago
        I do have a blog post planned on the topic that's hopefully only a few posts away, and a renewed commitment to start frequent blogging again. And this has all been off topic, so I'll spare the reply.
      - sgarland 1y ago
        uv has done for Python what Docker did for containers. Could you accomplish what Docker did with OS primitives like cgroups? Of course. Do most devs know what those are, much less how to use them? Doubtful. I consider myself to be fairly good with Python, and excellent with *nix. uv is far and away the best tool for managing Python projects, tools, and scripts, bar none. Sorry, Poetry - you had a good run.
elzbardico 1y ago
Everybody else uses virtual environments and alternate installations of python instead of using and installing packages in the system python installation. It is not that hard.
- zahlman 1y ago
  That is the incantation.
  - jimmaswell 1y ago
    I memorized it quickly enough from some time experimenting with cuda/ai tools. python -m venv . . bin/activate pip install -r requirements.txt
  - stavros 1y ago
    `uvx <tool name>` and you're done. You don't even need to install the tool first.
    - zahlman 1y ago
      The ephemeral environment that uv creates is as much an "installation" as the permanent one doing it manually.
      - stavros 1y ago
        The fact that you called one "ephemeral" and the other "permanent" makes me think you contradicted your own point.
        zahlman 1y ago
        No, I just don't think the word "install" has the same connotations that you apparently think it does.
zahlman 1y ago
These kinds of histrionics are really uncalled for. Virtual environments are easy to work with. https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... is a solid tutorial.
- dreamcompiler 1y ago
  Bookmarking this.
  - stavros 1y ago
    Don't, use `uv`. Literally just install uv and then try something like `uvx bakeit` and it'll download and run the tool in its own virtualenv. You don't need to bother with anything.
- wtallis 1y ago
  Virtual environments are an incomplete solution at best. In particular, they really don't help much with the use case of wanting to install a tool: if you're installing a tool and not just setting up a development environment for working on a specific project with its dependencies, then you probably want to make that tool usable without activating its venv. The virtual environment capabilities shipped with Python itself don't really have any affordances for that.
  - kalaksi 1y ago
    I don't get it. Then you just install the tool outside of venv? then it's installed for your user account.
    - tdeck 1y ago
      But then all the tool's dependencies have to play nice with the dependencies of all your other unrelated Python-based tools. One thing you can do (I'm not saying it's user friendly) is set up the tool in a virtualenv and then set up an alias like alias foo-tool=/home/blah blah/tools/something/env/bin/python -m foo-tool
jjcob 1y ago
Is Python still that bad? I remember the big problems were during the Python 2 -> Python 3 transition, but in the last few years I've managed to get away with a single Python install and haven't really had any compatibility issues. I stick with Python.org packages for macOS, and the official Python packages on Ubuntu, and everything seems to work just fine.
- swiftcoder 1y ago
  There are better tools for managing the madness, certainly. uv makes python management almost pleasant (sandboxing the whole environment by default is a wise choice).
  - NetMageSCW 1y ago
    That sounds like a good way to greatly increase the disk and ram required for each tool or running copy of a tool or application. Almost as bad as turning everything into an Electron app.
    - swiftcoder 1y ago
      You aren't wrong, but it's pretty much the only sane way to deal with an ecosystem that doesn't allow multiple versions of the same package to coexist - otherwise we're all stuck on the lowest common denominator of each configuration of packages
    - me-vs-cat 1y ago
      It may sound that way to you, but it doesn't have that problem for me.
kunley 1y ago
Ehm.. surely there are ecosystems making Python brilliant shiny in comparison.
pastage 1y ago
Any project written in a language with big user base java, C#, C++, perl, rust even fortran has this problem. The only thing that helps is experience with the language. I very seldom see code that survives ten years, even no deps things fail because your compiler interpreter changes. It is just part of the job. Sure I am not a big fan of C# or PowerShell but a big part is just that I have no experience.
- rwmj 1y ago
  Nope. Python has a habit of regularly breaking working stuff. It's a developer/community problem - the language itself doesn't require it.
  - pastage 1y ago
    I have never been a Python fan, but I wrote my first python application in Zope 26 years ago it still runs. Since then I have touched other things that are much worse not all of them on the list above. My point is that while python may break, other stuff breaks as well. There are a lot of prototype integration projects in Python though and that is incredibly hard to get running. I know nothing about C# but as Linus Torvalds said the binary compatibility layer for Linux is Win32 because of Steam, so MS has worked on the problem before. Though I would like to point out that when you are talking about prototype integration projects Windows is as bad as Python, I have rebuilt test environment in Windows that had been left to rot for ten years. So in my work life experience all programming languages suck at this, python might suck less or more but it is more of a skill issues than anything.
- NetMageSCW 1y ago
  That’s not generally true for .Net, though the use of third party libraries could create an issue in some cases. .Net was designed deliberately so that multiple versions could be installed side by side and an executable would pick the version most likely to work based on target version and compatibility. In most cases .Net is also forward compatible so e.g. a .Net 3 app continues to work on a PC where only .Net 4.8 is installed. In addition, libraries could be part of the application installation and in modern .Net, the framework can be part of the application installation. In most cases, everything will just work, and when it doesn’t, one can just install the older .Net version needed and nothing will be broken.

wtallis 1y ago

These days, if I'm feeling generous I'll spend a minute or two to see if I can get a promising Python tool to install with uv. If it's not going to easily submit to a `uv tool install`, then I move on and forget about it.

ecshafer 1y ago

UV has gone a long way to fix that issue with python.

zahlman 1y ago
uv has not really done that much. It's all been possible, and usually about as ergonomically. It's just opinionated in a way that people currently seem to like, and fast primarily due to good internal design (not because it's written in rocket emoji Rust sparkle emoji, although that certainly is a net positive to performance).
- lmm 1y ago
  UV hasn't done anything except for all the parts that matter. (And while there are compelling arguments that Rust has nothing to do with it, the correlation is pretty strong)
  - noitpmeder 1y ago
    UV has provided easy solutions for engineers that are easily frustrated by a lack of easy solutions. There's nothing wrong with easy solutions, but any python engineer worth their salt has long since solved and moved on from the issues that UV claims to solve. I believe UV provides value, even significant value, to lite python users, but for those working with python day in and day out, maybe you're using a new tool, but life has not changed significantly for the better. Or you just sucked and didn't reach for any of the perfectly usable solutions to all of these problems that existed before UV showed up.
    - wtallis 1y ago
      uv provides a breadth of functionality that no single tool has before, and that no simple, easy combination of tools has before. For developers, it replaces poetry with something much faster and more reliable, and replaces pipenv. For end users, it replaces pipx and pyenv, and pretty much replaces pip itself (which no longer wants to be used by end users). And most importantly, uv relieves you of having to remember which of the preceding tools are suitable for which use cases.
      - zahlman 1y ago
        I do have a blog post planned on the topic that's hopefully only a few posts away, and a renewed commitment to start frequent blogging again. And this has all been off topic, so I'll spare the reply.
    - sgarland 1y ago
      uv has done for Python what Docker did for containers. Could you accomplish what Docker did with OS primitives like cgroups? Of course. Do most devs know what those are, much less how to use them? Doubtful. I consider myself to be fairly good with Python, and excellent with *nix. uv is far and away the best tool for managing Python projects, tools, and scripts, bar none. Sorry, Poetry - you had a good run.

elzbardico 1y ago

Everybody else uses virtual environments and alternate installations of python instead of using and installing packages in the system python installation. It is not that hard.

zahlman 1y ago
That is the incantation.
- jimmaswell 1y ago
  I memorized it quickly enough from some time experimenting with cuda/ai tools. python -m venv . . bin/activate pip install -r requirements.txt
- stavros 1y ago
  `uvx <tool name>` and you're done. You don't even need to install the tool first.
  - zahlman 1y ago
    The ephemeral environment that uv creates is as much an "installation" as the permanent one doing it manually.
    - stavros 1y ago
      The fact that you called one "ephemeral" and the other "permanent" makes me think you contradicted your own point.
      - zahlman 1y ago
        No, I just don't think the word "install" has the same connotations that you apparently think it does.

zahlman 1y ago

These kinds of histrionics are really uncalled for. Virtual environments are easy to work with. https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... is a solid tutorial.

dreamcompiler 1y ago
Bookmarking this.
- stavros 1y ago
  Don't, use `uv`. Literally just install uv and then try something like `uvx bakeit` and it'll download and run the tool in its own virtualenv. You don't need to bother with anything.
wtallis 1y ago
Virtual environments are an incomplete solution at best. In particular, they really don't help much with the use case of wanting to install a tool: if you're installing a tool and not just setting up a development environment for working on a specific project with its dependencies, then you probably want to make that tool usable without activating its venv. The virtual environment capabilities shipped with Python itself don't really have any affordances for that.
- kalaksi 1y ago
  I don't get it. Then you just install the tool outside of venv? then it's installed for your user account.
  - tdeck 1y ago
    But then all the tool's dependencies have to play nice with the dependencies of all your other unrelated Python-based tools. One thing you can do (I'm not saying it's user friendly) is set up the tool in a virtualenv and then set up an alias like alias foo-tool=/home/blah blah/tools/something/env/bin/python -m foo-tool

jjcob 1y ago

Is Python still that bad? I remember the big problems were during the Python 2 -> Python 3 transition, but in the last few years I've managed to get away with a single Python install and haven't really had any compatibility issues. I stick with Python.org packages for macOS, and the official Python packages on Ubuntu, and everything seems to work just fine.

swiftcoder 1y ago
There are better tools for managing the madness, certainly. uv makes python management almost pleasant (sandboxing the whole environment by default is a wise choice).
- NetMageSCW 1y ago
  That sounds like a good way to greatly increase the disk and ram required for each tool or running copy of a tool or application. Almost as bad as turning everything into an Electron app.
  - swiftcoder 1y ago
    You aren't wrong, but it's pretty much the only sane way to deal with an ecosystem that doesn't allow multiple versions of the same package to coexist - otherwise we're all stuck on the lowest common denominator of each configuration of packages
  - me-vs-cat 1y ago
    It may sound that way to you, but it doesn't have that problem for me.

kunley 1y ago

Ehm.. surely there are ecosystems making Python brilliant shiny in comparison.

pastage 1y ago

Any project written in a language with big user base java, C#, C++, perl, rust even fortran has this problem. The only thing that helps is experience with the language. I very seldom see code that survives ten years, even no deps things fail because your compiler interpreter changes. It is just part of the job. Sure I am not a big fan of C# or PowerShell but a big part is just that I have no experience.

rwmj 1y ago
Nope. Python has a habit of regularly breaking working stuff. It's a developer/community problem - the language itself doesn't require it.
- pastage 1y ago
  I have never been a Python fan, but I wrote my first python application in Zope 26 years ago it still runs. Since then I have touched other things that are much worse not all of them on the list above. My point is that while python may break, other stuff breaks as well. There are a lot of prototype integration projects in Python though and that is incredibly hard to get running. I know nothing about C# but as Linus Torvalds said the binary compatibility layer for Linux is Win32 because of Steam, so MS has worked on the problem before. Though I would like to point out that when you are talking about prototype integration projects Windows is as bad as Python, I have rebuilt test environment in Windows that had been left to rot for ten years. So in my work life experience all programming languages suck at this, python might suck less or more but it is more of a skill issues than anything.
NetMageSCW 1y ago
That’s not generally true for .Net, though the use of third party libraries could create an issue in some cases. .Net was designed deliberately so that multiple versions could be installed side by side and an executable would pick the version most likely to work based on target version and compatibility. In most cases .Net is also forward compatible so e.g. a .Net 3 app continues to work on a PC where only .Net 4.8 is installed. In addition, libraries could be part of the application installation and in modern .Net, the framework can be part of the application installation. In most cases, everything will just work, and when it doesn’t, one can just install the older .Net version needed and nothing will be broken.