So I’m no expert, but I have been a hobbyist C and Rust dev for a while now, and I’ve installed tons of programs from GitHub and whatnot that required manual compilation or other hoops to jump through, but I am constantly befuddled installing python apps. They seem to always need a very specific (often outdated) version of python, require a bunch of venv nonsense, googling gives tons of outdated info that no longer works, and generally seem incredibly not portable. As someone who doesn’t work in python, it seems more obtuse than any other language’s ecosystem. Why is it like this?

  • pixelscript@lemm.eeEnglish
    52·
    6 days ago

    Python is the only programming language that has forced me to question what the difference is between an egg and a wheel.

  • JackbyDev@programming.devEnglish
    35·
    6 days ago

    No, it’s not just you, Python’s tooling is a mess. It’s not necessarily anyone’s fault, but there are a ton of options and a lot of very similarly named things that accomplish different (but sometimes similar) tasks. (pyenv, venv, and virtualenv come to mind.) As someone who considers themselves between beginner and intermediate proficiency in Python, this is my biggest hurdle right now.

    • NostraDavid@programming.dev
      15·
      6 days ago

      Python’s tooling is a mess.

      Not only that. It’s a historic mess. Over the years, growing a better and better toolset left a lot of projects in a very messy state. So many answers on Stack Overflow that mention easy_install - I still don’t know what it is, but I guess it was some kind of proto uv.

      • JackbyDev@programming.devEnglish
        6·
        6 days ago

        Every time I’m doing anything with Python I ask myself if Java’s tooling is this complicated or I’m just used to it by now. I think a big part of the weirdness is that a lot of Python tooling is tied to the Python installation whereas in Java things like Maven and Gradle are separate. In addition, I think dependencies you install get tied to that Python installation, while in Java they just are in a cache for Maven/Gradle. And in the horrible scenario where you need to use different versions of Maven/Gradle (one place I was at specifically needed Maven 3.0.3 for one project and a different for a different, don’t ask, it’s dumb and their own fault for setting it up that way) at least they still have one common cache for everything.

        I guess it also helps that with Java you (often) don’t need platform specific jar files. But Python is often used as an easy and dynamic scripting interface over more performant, native code. So you don’t really run into things like “this artifact doesn’t have a 64 bit arm version for python 2” often with Java. But that’s not a fault of Python’s tooling, it’s just the reality of how it’s used.

  • nucleative@lemmy.worldEnglish
    303·
    7 days ago

    Python developer here. Venv is good, venv is life. Every single project I create starts with

    python3 -m venv venv

    source venv/bin/activate

    pip3 install {everything I need}

    pip3 freeze > requirements.txt

    Now write code!

    Don’t forget to update your requirements.txt using pip3 freeze again anytime you add a new library with pip.

    If you installed a lot of packages before starting to develop with virtual environments, some libraries will be in your OS python install and won’t be reflected in pip freeze and won’t get into your venv. This is the root of all evil. First of all, don’t do that. Second, you can force libraries to install into your venv despite them also being in your system by installing like so:

    pip3 install --ignore-installed mypackage

    If you don’t change between Linux and windows most libraries will just work between systems, but if you have problems on another system, just recreate the whole venv structure

    rm -rf venv (…make a new venv, activate it) pip3 install -r requirements.txt

    Once you get the hang of this you can make Python behave without a lot of hassle.

    This is a case where a strength can also be a weakness.

    • NostraDavid@programming.dev
      20·
      6 days ago

      pip3 freeze > requirements.txt

      I hate this. Because now I have a list of your dependencies, but also the dependencies of the dependencies, and I now have regular dependencies and dev-dependencies mixed up. If I’m new to Python I would have NO idea which libraries would be the important ones because it’s a jumbled mess.

      I’ve come to love uv (coming from poetry, coming from pip with a requirements/base.txt and requirements/dev.txt - gotta keep regular dependencies and dev-dependencies separate).

      uv sync

      uv run <application>

      That’s it. I don’t even need to install a compatible Python version, as uv takes care of that for me. It’ll automatically create a local .venv/, and it’s blazingly fast.

      • nucleative@lemmy.worldEnglish
        2·
        6 days ago

        I’ve never really spent much time with uv, I’ll give it a try. It seems like it takes a few steps out of the process and some guesswork too.

    • tyler@programming.dev
      6·
      5 days ago

      You have been in lala land for too long. That list of things to do is insane. Venv is possibly one of the worst solutions around, but many Python devs are incapable of seeing how bad it is. Just for comparison, so you can understand, in Ruby literally everything you did is covered by one command bundle. On every system.

      • megaman@discuss.tchncs.de
        4·
        6 days ago

        The git repo should ignore the venv folder, so when you clone you then create a new one and activate it with those steps.

        Then when you are installing requirements with pip, the repo you cloned will likely have a requirements.txt file in it, so you ‘pip install -r requirements.txt’

    • oldfart@lemm.ee
      6·
      6 days ago

      OP sounds like a victim of Python 3, finding various Python 2 projects on the internet, a venv isn’t going to help

  • FizzyOrange@programming.dev
    31·
    7 days ago

    Yes it’s terrible. The only hope on the horizon is uv. It’s significantly better than all the other tooling (Poetry, pip, pipenv, etc.) so I think it has a good chance of reducing the options to just Pip or uv at least.

    But I fully expect the Python Devs to ignore it, and maybe even make life deliberately difficult for it like they did for static analysers. They have some strange priorities sometimes.

    • flubba86@lemmy.world
      8·
      7 days ago

      I like the idea of uv, but I hate the name. Libuv is already a very popular C library, and used in everything from NodeJS to Julia to Python (through the popular uvloop module). Every time I see someone mention uv I get confused and think they’re talking about uvloop until I remember the Astral project, and then reconfirm to myself how much I disapprove of their name choice.

      • FizzyOrange@programming.dev
        2·
        6 days ago

        I don’t think libuv is really that popular, nor is it that confusing.

        But I do agree it’s not a very good name. “Rye” is a much better name. Probably too late anyway.

    • tempest@lemmy.ca
      32·
      6 days ago

      uv is good but it needs a little more time in the oven.

      For the moment I would definitely recommend poetry if you are not a library developer. Poetry’s biggest sin is it’s atrocious performance but it has most of the features you need to work with Python apps today.

      • FizzyOrange@programming.dev
        3·
        6 days ago

        Why do you say it needs more time in the oven? I’ve had zero issues with it as a drop-in replacement for Pip in a large commercial project, which is an extremely impressive achievement. (And it was 10x faster.)

        I tried Poetry once and it failed to resolve dependencies on the first thing I tried it on. If anything Poetry needs more time in the oven. It also wasn’t 10x faster.

  • WolfLink@sh.itjust.works
    20·
    7 days ago

    The reason you do stuff in a venv is to isolate that environment from other python projects on your system, so one Python project doesn’t break another. I use Docker for similar reasons for a lot of non-Python projects.

    A lot of Python projects involve specific versions of libraries, because things break. I’ve had similar issues with non-Python projects. I’m not sure I’d say Python is particularly worse about it.

    There are tools in place that can make the sharing of Python projects incredibly easy and portable and consistent, but I only ever see the best maintained projects using them unfortunately.

      • flubba86@lemmy.world
        5·
        7 days ago

        I’ve been full time writing python professionally since 2015. You get used to it. It starts to just make sense and feel normal. Then when you move to a different language environment you wonder why their tooling doesn’t use a virtualenv.

        • Lettuce eat lettuce@lemmy.ml
          1·
          6 days ago

          I’m starting to get the hang of it. I was using Debian, so I had to figure out the basics of venv because many of the frameworks I was trying to learn require newer versions of Python than what comes with Debian.

          vscodium works really easily inside it though, so it wasn’t too bad, but I still feel like I’m treading water a little bit.

  • vin@lemmynsfw.comEnglish
    2·
    7 days ago

    Yep, they are not portable, every app should come bundled with its own interpreter. As to why, I think historically it didn’t target production grade application development.

        • flying_sheep@lemmy.ml
          11·
          7 days ago

          It’s not a standard, it’s built on standards.

          You can also use Poetry (which recently grew standard metadata support) or plain uv venv if you want to do things manually but fast.

          • Zykino@programming.dev
            5·
            6 days ago

            Just use this one… or any of this 4 others.

            This is the issue for us, python outsiders. Each time we try we get a different answer with new tools. We are outside of the comtunity, we don’t know the trend, old and new, pro and cons.

            Your first recommandation is hatch… first time I’ve heard of it. Uv seems trendy in this thread, but before that it was unknown to me too.

            As I understands it, it should be pip’s job. When it detect I’m in a project it install packages in it and python use them. It can use any tool under the hood, but the default package manager shoud be able to do it on its own.

            • flying_sheep@lemmy.ml
              2·
              6 days ago

              Uv and pip do the same thing, uv is just faster.

              Hatch has the same role as Poetry or tox: managing environments for you.

              Applications should be packaged properly, in a self contained installer for exactly this demographic. It’s not Python’s fault that this isn’t common practice.

  • N0x0n@lemmy.ml
    11·
    7 days ago

    Just out of curiosity, I haven’t seen anyone recommend miniconda… Why so, is there something wrong I’m not aware of?

    I’m no expert, but I totally feel you, python packages, dependencies and version matching is a real nightmare. Even with venv I had a hard time to make everything work flawlessly, especially on MacOS.

    However, with miniconda everything was way easier to configure and worked as expected.

  • nickwitha_k (he/him)@lemmy.sdf.org
    71·
    7 days ago

    Python’s packaging is not great. Pip and venvs help but, it’s lightyears behind anything you’re used to. My go-to is using a venv for everything.

  • solrize@lemmy.world
    601·
    7 days ago

    It’s something of a “14 competing standards” situation, but uv seems to be the nerd favourite these days.

    • iii@mander.xyzEnglish
      30·
      7 days ago

      I still do the python3 -m venv venv && source venv/bin/activate

      How can uv help me be a better person?

      • NostraDavid@programming.dev
        7·
        6 days ago
        1. let pyproject.toml track the dependencies and dev-dependencies you actually care about
        • dependencies are what you need to run your application
        • dev-dependencies are not necessary to run your app, but to develop it (formatting, linting, utilities, etc)
        1. it can track exactly what’s needed ot run the application via the uv.lock file that contains each and every lib that’s needed.
        2. uv will install the needed Python version for you, completely separate from what your system is running.
        3. uv sync and uv run <application> is pretty much all you need to get going
        4. it’s blazingly fast in everything
        • iii@mander.xyzEnglish
          2·
          6 days ago

          Thank you for explaining so clearly. Point 3 is indeed something I’ve ran into before!

      • PartiallyApplied@lemmy.world
        3·
        7 days ago

        If you’re happy with your solution, that’s great!

        uv combines a bunch of tools into one simple, incredibly fast interface, and keeps a lock file up to date with what’s installed in the project right now. Makes docker and collaboration easier. Its main benefit for me is that it minimizes context switching/cognitive load

        Ultimately, I encourage you to use what makes sense to you tho :)

    • QuazarOmega@lemy.lol
      31·
      7 days ago

      This! Haven’t used that one personally, but seeing how good ruff is I bet it’s darn amazing, next best thing that I used has been PDM and Poetry, because Python’s first party tooling has always been lackluster, no cohesive way to define a project and actually work it until relatively recently

      • NostraDavid@programming.dev
        4·
        6 days ago

        I bet it’s darn amazing,

        It is. In this older article (by Anna-Lena Popkes) uv is still not in the middle, but I would claim it’s the new King of Project Management, when it comes to Python.

        uv init --name <some name> --package --app and you’re off to the races.

        Are you cloning a repo that’s uv-enabled? Just uv sync and you’re done!

        Heck, you can now add dependencies to a script and just uv run --script script.py (IIRC) and you don’t need to install anything - uv will take care of it all, including a needed Python version.

        Only downside is that it’s not 1.0 yet, so the API can change at any update. That is the last hurdle for me.

      • scrion@lemmy.world
        51·
        7 days ago

        I moved all our projects (and devs) from poetry to uv. Reasons were poetry’s non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don’t notice and believe it is stuck (even though it’s in the default project README).

        Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it’s smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental “flow” state while staring at updates, becoming suspicious something might be wrong. Don’t get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.

        Recently, “uv build” was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. “dev”) have made it to uv, too.

        “uv pip” does some things differently, in particular when resolving packages (it’s possible to switch to pip’s behavior now), but I do agree with the decisions, in particular the changes to prevent “dependency confusion” attacks.

        As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.

        cargo is a bit of an “unfair” comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.

        The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user’s cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.

        cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn’t need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.

        Finally, I’d also recommend to go and try setting up a project using astral’s uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa’s project management, pretty much an alternative to poetry or uv.

        uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons

        If you use workspaces in cargo, uv also does those.

        uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.

        • QuazarOmega@lemy.lol
          1·
          7 days ago

          I think you responded to the wrong comment, I didn’t question the need for uv or other tools like that

          • scrion@lemmy.world
            3·
            6 days ago

            I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP’s original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.

  • kSPvhmTOlwvMd7Y7E@programming.dev
    50·
    7 days ago

    You re not stupid, python’s packaging & versionning is PITA. as long as you write it for yourself, you re good. As soon as you want to share it, you have a problem

    • MajorHavoc@programming.dev
      171·
      7 days ago

      as long as you write it for yourself, you re good. As soon as you want to share it, you have a problem

      A perfect summary of the history of computer code!

  • lime!@feddit.nuEnglish
    23·
    7 days ago

    everyone focuses on the tooling, not many are focusing on the reason: python is extremely dynamic. like, magic dynamic you can modify a module halfway through an import, you can replace class attributes and automatically propagate to instances, you can decompile the bytecode while it’s running.

    combine this with the fact that it’s installed by default and used basically everywhere and you get an environment that needs to be carefully managed for the sake of the system.

    js has this packaging system down pat, but it has the advantage that it got mainstream in a sandboxed isolated environment before it started leaking out into the system. python was in there from the beginning, and every change breaks someone’s workflow.

    the closest language to look at for packaging is probably lua, which has similar issues. however since lua is usually not a standalone application platform it’s not a big deal there.

    • tyler@programming.dev
      1·
      5 days ago

      and yet that all works fine in Ruby, which came out around the same time as Python and yet has had Bundler for 15 years now.

      Python - 15+ package managers and build tools Ruby - 1

      the closest language to look at for packaging is probably lua, which has similar issues. however since lua is usually not a standalone application platform it’s not a big deal there.

      no the closest language is literally Ruby, it’s almost the exact same language, except the tooling isn’t insane and it came out only a few years after python.

      • lime!@feddit.nuEnglish
        2·
        5 days ago

        good point, ruby is a good comparison. although, ruby is very different under the hood. it’s magically dynamic in a completely different way, and it also never really got the penetration on the system level that python did.

        none of this is to take away from the fact that python packaging is bad. i know how to work it because i’ve been programming in python for 14 years, but trying to teach people makes the problem obvious. and yet.