13 ms·

> Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros That's kind of very op

• nikisweeting 1y ago
  this is solved by uv
  • CoolCold 1y ago
    > things like virtual envs I consider my point as still valid with UV, what you wanted to express? On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.
    • charliermarsh 1y ago
      uv works just as well with whatever Python you want to bring -- you're not required to use the Pythons that uv is capable of installing on your machine.
  • jauntywundrkind 1y ago
    uv really is working super super super hard to absolve decades of sins and blood in the python world. and doing a good job at redemption.
• acdha 1y ago
  “import json” is the kind of thing which requires picking and installing libraries in batteries-not-included languages, and it’s just one of many modules which are in the standard library. That’s not a compelling basis for large projects but over the years I’ve shipped a ton of useful production code which never needed more than the stdlib and thus spent no time at all thinking about deployment or security patching. Also, it’s not the 2000s any more. Using venv to isolate application installs is not very hard anymore and there have been decent package managers for a long time.
  • frollogaston 1y ago
    The official package manager is pip, it's broken, and there has been a new "permanent solution" replacement for it each year.
    • acdha 1y ago
      “broken” is hyperbole. It works fine for millions of people every day. If you have some specific scenarios where you want it be better, it’s better to say those rather than just complain about an open source project.
      • frollogaston 1y ago
        Millions of people put it into Docker, or they just deal with it and you see the results with tons of Stackoverflow questions
        • BeetleB 1y ago
          > Millions of people put it into Docker, or they just deal with it and you see the results with tons of Stackoverflow questions Arrogantly wrong. I've coded in Python for almost 20 years. Many of those years I've had it as my primary language at work. 2024 was the first year I actually needed a virtualenv. Before that, I'd happily use pip to install whatever I want, and never had a version conflict that caused problems. I often encounter junior folks who default to using a virtualenv, not because they need to, but because they've been brainwashed into believing that "you're doing it wrong if you don't use one". In any case, people should use uv these days.
          • frollogaston 1y ago
            I was talking about pip, not venv. I don't use venv either, not because I think it's a bad idea but because I can't be bothered. Stuff does end up conflicting unless I use Docker (lol) or uv.
• wpm 1y ago
  I have a silly theory that I only half joke about that docker/containers wouldn't've ever taken off as fast as it did if it didn't solve the horrible python dependency hell so well. You know something is bad when fancy chrooting is the only ergonomic way of shipping something that works. My first taste of Python was as a sysadmin, back in 2012 or so, installing a service written in Python on a server. The dependency hell, the stupid venv commands, all this absolute pain just to get a goddamn webserver running, good lord. It turned me off of Python for over a decade. Almost any time I saw it I just turned and walked away, not interested, no thanks. The times I didn't, I walked right back into that pile of bullshit and remembered why I normally avoided it. The way `brew` handles it on macOS is also immensely frustrating, breaking basic pip install commands, installing libraries as commands but in ways that make them not available to other python scripts, what a goddamn disaster. And no, I really have no clue what I'm talking about, because as someone starting out this has been so utterly stupid and bewildering that I just move on to more productive, pleasant work with a mental note of "maybe when Python gets their shit together I'll revisit it". However, uv has, at least for my beginner and cynical eyes, swept away most of the bullshit for me. At least superficially, in the little toy projects I am starting to do in Python (precisely because its such a nicer experience), it sweeps away most of the horrid bullshit. `uv init`, `uv add`, `uv run`. And it just works*.
  • stanleydrew 1y ago
    > I have a silly theory that I only half joke about that docker/containers wouldn't've ever taken off as fast as it did if it didn't solve the horrible python dependency hell so well. I don't think this is a silly theory at all. The only possibly silly part is that containers specifically helped solve this problem just for python. Lots of other software systems built with other languages have "dependency hell."
    • bb88 1y ago
      Back in the early days of Redhat, rpm's didn't really have good dependency management. Yes there were rpms, yes you could download them, but getting the full dep tree was a PITA. Most people installed the full Linux distro rather than a lightweight version because of this. Debian's apt-get was very "apt" at the time when it came out. It solved the entire issue for Debian. There was a point at which there was an apt-rpm for redhat. Yum tried to solve it for redhat, but didn't really work that well -- particularly if you needed to pin packages to certain versions.
• turtlebits 1y ago
  You should always use virtual envs. They're a single directory, how are they an abyss? Pip now complains if you try to install a package system wide.
  • unethical_ban 1y ago
    For shadow IT, anything that requires "installation" vs. being in the base system or being added as a file to a project is an inconvenience. It's why I like using Bottle for small Python frontends: download the file and import. (I'm ranting based on personal experiences with IT in the past. Yes in general virtualenv is the baseline)
    • ActorNightly 1y ago
      Compile python to executable is always an option.
      • shakna 1y ago
        If you're dealing with a managed system, chances are, compilers are banned. You'll have to be unsafe and work outside the constrained environment - potentially violating policies, contracts, regulations and laws.
  • nomel 1y ago
    > You should always use virtual envs. If you're not using dependencies, and are writing 3.x code, there's very little justification.
    • dapperdrake 1y ago
      Not using dependencies is rather niche. Most people come to Python because they want to use pre-existing libraries.
  • frollogaston 1y ago
    I don't have to deal with this in JS or I think in other stuff like Golang. I give someone a package.json with versions of everything. npm install always sets deps up locally, but doesn't need to copy the entire NodeJS runtime.
• ziml77 1y ago
  Yes, please use virtual envs or containers. I know it seems overly heavy and hard to manage, but you don't want to end up in a situation where you're afraid to update the system because the library upgrades might break some of your Python code.
• ActorNightly 1y ago
  No and no. I don't know how you even get to this level of "making it harder for yourself". Say you want to use a specific version of python that is not available on Ubuntu. 1. Install build dependencies https://devguide.python.org/getting-started/setup-building/#install-dependencies https://devguide.python.org/getting-started/setup-building/#... 2. Download whichever Python source version you want, https://www.python.org/downloads/source/ https://www.python.org/downloads/source/. Extract it with tar 3. run ./configure --enable-optimizations --with-lto 4. run make -s -j [num cores] 5. sudo make altinstall This will install that specific version without overwriting default system python. You can then bash alias pip to python3.xx -m pip to make sure it runs the correct one. All the libraries and any pip install executable will be installed locally to ~/.local folder under the specific python version. Alternatively, if you work with other tools like node and want to manage different versions, you can use asdf, as it gives you per folder version selection. virtual environments are really only useful for production code, where you want to test with specific versions and lock those down.
  • icedchai 1y ago
    Personal preference, but I prefer to use 'mise' instead of 'asdf' these days: https://mise.jdx.dev/ https://mise.jdx.dev/
  • dragonwriter 1y ago
    Virtual environments are useful for isolating dependencies for different projects, not just isolating the interpreter. (I mean, except on Windows, your venvs default to symlinking the interpreter and other shared bits, so you aren't really isolating the interpreter at all, just the dependencies.)
    • ElectricalUnion 1y ago
      AFAIK, it's the same even on POSIX, when you create a venv, "./bin/python" are symlinks and the pyvenv.cfg has a hardcoded absolute path of the current python interpreter the venv module was using at the time of creation. It really doesn't isolate the interpreter. (also one of the reasons why, if you're invoking venv manually, you absolutely need to invoke it from the correct python as a module (`python3.13 -m venv`) to make sure you're actually picking the "correct python" for the venv)
• frollogaston 1y ago
  Also in some older cases the pre-included Python is v2 and the system relies on it, which is more of a liability.
• geysersam 1y ago
  Just use uv
  • IshKebab 1y ago
    I agree - Python without uv is masochistic. But that really negates the "Python is already available" advantage. If you have to install uv you can just as easily install Rust or Go or Deno.
• zahlman 1y ago
  I agree that the built-in Python is typically not suitable for development, especially if you're planning to distribute your code and/or care about the versions of its dependencies. (And especially on Debian and its derivatives, in my experience; they even remove parts of the standard library, like Tkinter [0].) I disagree that virtual environments represent an "abyss". It takes very little effort to learn how they work [1], plus there a variety of tools that will wrap the process in various opinionated ways [2]. The environment itself is a very simple concept and requires very few moving parts; the default implementation includes some conveniences that are simply not necessary. In particular, you don't actually need to "activate" a virtual environment; in 99% of cases you can just run Python by specifying the path to the environment's Python explicitly, and in the exceptional cases where the code is depending on environment variables being set (e.g. because it does something like `subprocess.call(['python', 'foo.py'])` to run more code in a new process, instead of checking `sys.executable` like it's supposed to, or because it explicitly checks `VIRTUAL_ENV` because it has a reason to care about activation) then you can set those environment variables yourself. Creating a virtual environment is actually very fast. The built-in `venv` standard library module actually does it faster in my testing than the equivalent `uv` command. The slow part is bootstrapping Pip from its own wheel - but you don't need to do this [2]. You just have to tell `venv` not to, using `--without-pip`, and then you can use a separate Pip (for recent versions — almost the last 3 years now) copy cross-environment using `--python` (it's a hack, but it works if you don't have to maintain EOL versions of anything). If you need heavy-duty support, there's also the third-party `virtualenv` [3]. Much of the same tooling that manages virtual environments for you — in particular, pipx and uv, and in the hopefully near future, PAPER [4] — also does one-off script runs in a temporary virtual environment, installing dependencies described in the script itself following a new ecosystem standard [5]. Uv's caching system (and of course I am following suit) makes it very fast to re-create virtual environments with common dependencies: it has caches of unpacked wheel contents, so almost all of the work is just hard-linking file trees into the new environment. [0]: https://stackoverflow.com/questions/76105218 https://stackoverflow.com/questions/76105218 [1]: https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... [2]: https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... [3]: https://virtualenv.pypa.io/ https://virtualenv.pypa.io/ [4]: https://github.com/zahlman/paper https://github.com/zahlman/paper [5]: https://peps.python.org/pep-0723 https://peps.python.org/pep-0723
• _ea1k 1y ago
  +1 - I've been shocked at how many little portability issues that I've had shipping software, even within the relatively constrained environment of fellow employees. Minor differences between distro versions can make a big difference, and not everyone that uses a Python script knows how to use something like pyenv to manage different versions.
• dapperdrake 1y ago
  More like a snake pit than a can of worms.