How to improve Python packaging

conda is a bleeding pain in the ass; installed a ton of stuff without even asking if I needed them. Then when I wanted to install a different version of Python, kept running conflict resolution for hours before I got tired and killed it. Might as well just do the setup oldschool via virtualenv using requirements.txt.

Dealing with all this is why I chose to use golang for writing a CLI utility (even though I'm not a big fan of its error handling boilerplate); static typing + produces a single binary that can be run without needing any of the environment setup. I am aware of various Python tools that can produce a binary too but I think they have their own edge cases and it is just nicer when that can be done out of the box without any dependencies.

> You can also find deficiencies in the tools for the other languages mentioned. Some people think Maven is terrible because it uses XML and Gradle is the way to go, and others think Gradle’s use of a Groovy-based DSL makes things much harder than they need to be and prefer Maven instead.

Yeah but I have never had the installer crap out like pip or its ilk do when installing a package with maven. At worst, it can't find the package if the repositories are not configured properly.

So we should all use PDM then as it's the best so far among all others? I read it somewhere once in the past but never used it. I just use `venv + pip` all the time so far, worked well for my case though.

I think this is what success for unification looks like:

Let's say there are two tools, one called pyup and one called pygo.

    pyup: responsible for which versions of python are available on your machine, as well 
          as which one is the default "system" python. It also keeps itself and pygo updated.

    pygo: responsible for (among other things) 
          - allowing a user to specify a python version for a project
          - allowing a user to specify a python version for a script
          - helping the user install a compatible python version for the project with pyup
          - helping the user install a compatible python version for a script with pyup
          - selecting a compatible python version/env for project
          - selection a compatible python version/env for a script
          - allowing a user to specify project dependencies
          - allowing a user to specify script dependencies within a script
          - determining which dependencies are required for a project
          - determining which dependencies are required for a script
          - installing project dependencies
          - installing script dependencies
          - installing projects or scripts as executables

I MUST NOT need a base python install to make any of this work. Tools are constantly mucking with system python and which one is on my path so I can't trust system python, period. pyup and pygo should be their own binaries which invoke python. example.py:

    #!/usr/bin/env pygo
    # version: ~3.11
    # requirements:
    #    requests~=2
    import requests
    requests.get("https://example.com")

When I run ./example.py for the first time:

    - pygo helps me install python 3.11
    - pygo installs requests in a location that I don't have to worry about

When I run ./example.py for the second time, the script runs without error.

If I still need to use something like virtualenv, poetry, or conda on top of this, the unification project has failed.

And one of the reasons I moved away from it! My blog post on the subject was posted here and it was very unpopular despite having similar points and also making comparisons with Node.

There's nothing special about Python that makes it worth enduring this pain. We have other languages with a better developer UX.

It's not really solved if you have no choice but to work with codebases that don't use Poetry (quite common). There's 14 tools for people to choose from that aren't going away any time soon.