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.