+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind.

Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default.

It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a checker that can avoid many bugs.

But this. The package manager. We can compete. And yet we are late.

It's partially my fault since it's a project I had in mind for years and never took the time to work on. It's partially everybody's fault I guess :)

This is actually one of the big problems, I think: Python packaging involves knowing a number of different things and reading various resources to get the full picture.

Recently, I built a small CLI tool in Python, and learned all of the bits needed to build, test and package my application "the right way". I knew Python syntax before, but it was a lot of effort to set this up. The difference in the experience between Python and Rust or .NET Core is actually shocking, and most it isn't down to anything that Python couldn't do, just the current state of the tooling.

Conda is great software but the Conda/Anaconda ecosystem is a mess.

One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph.

Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta (http://nuitka.net/) for this. It's a fantastic project, but man it's a lot of work for something that works out of the box in Go or Rust.

One last thing is to generate packages for OS (msi/deb/rpm/dmg/snap). Your sysadmin will like you. Pex (https://pypi.python.org/pypi/pex) is the closest, but not very standard.

Other pet peeves of mine:

- you can't easily move virtualenvs;

- creating a setup.py is very hard for a beginner and has numerous traps;

- setup.py are executable files. Meh.

- what's with this setup.cfg containing 2 lines ? And the MANIFEST.IN being a separate files. Why do I have to put conf also in tox.ini ? And one for each of my linters ? I want ONE setup.cfg file with all config for all tools for my project inside and be done with it. TOML can handle rich sections, just stop creating new files.

- accessing file with pkg_resources() is way harder than it should be. I made a wrapper for this (http://sametmax.com/embarquer-un-fichier-non-python-propreme...).

- one place to have __version__, please. I want it readable in my code AND in my package metadata, without having to use regex or have side effects on imports.

- remove the "can't build wheel message" when it's useless. It scares newcomers.

- README is the long_description. Don't make me read it manually.

- how do I provide vendors in a clean way ?

- install_requires, extras_requires, setup_requires, tests_requires... Make it one require with hooks and tags and be done with it.

- creating a setup.py test config is way harder than it should be and breaks in CI on strange edge cases.

- can we get a PEP on the standard project structure and built it in our tools to be done with it? We all have src/package + setup.py on root anyway.

- pip installs packages in the site-packages dir of the python executable it's installed for. It makes sense, and I think Python deals pretty well with the fact you can have various versions installed on the same machine. But God people are confused by this. Now you can recommend to do "python -m pip", but it's very verbose and it assumes people know what version of Python is behind the "python" executable. On windows it can be any, and they must chose with... yet another command ("py")! pipenv just bypass that by assuming you want a virtualenv, and be able to access it. It's a very good call.

- pip install --user will create commands you can't use unless you edit your PATH. This makes newcomers go mad.

Pip is built on top of setuptools/distutils, so you are using them without even knowing it.

Why should it generate a deb file? How is this useful on anything but Debian based systems?

Why exe? How do you package libraries using this new tool you are envisioning?

I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all over the place to fix paths), and I find it semi-annoying to have a bunch of different copies of interpreter and all that goes with it (though this is mostly a minor annoyance -- it doesn't take up that much space and it doesn't matter if it gets out of sync.

Also notable, IMO, is the lack of a tool like rbenv or rustup for python. I can't tell you how many times I have had to try to figure out which python version a given pip executable worked with.

[0] https://news.ycombinator.com/item?id=13460490

I actually really love `Cargo` : the rust package manager.

Comments that make a single unambiguous point are fine. It's no problem to leave detailed support to replies.

A more controversial statement with the same content probably wouldn't have been voted up, but thread parent is objectively true even though it doesn't contain its own proof.

Thanks.

Actually we could also learn from:

- the JS community. npm dependancy graph, webpack resolver and yarn performances;

- the rust community like with cargo.

> Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of.

The nearest equivalent is to place a file called '.ruby-version' in the top level directory, containing the version number of the Ruby you want to use. Version numbers come from https://github.com/rbenv/ruby-build/tree/master/share/ruby-b.... rbenv, chruby and rvm all support .ruby-version.

One difference from virtualenv is that the Ruby version managers share single installations of each version of Ruby. My understanding from occasional use of Virtualenv is that it copies the python installation into a new per-project subdirectory, which seems a bit wasteful to me.

> You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now.

Yes, this is what I do. It gives me a shared 'clean' Ruby installation of the right version, plus a project-specific copy of all the gems the project depends on. To me this provides the best trade off between project isolation and not duplicating the whole world. You can set bundler up so this is done automatically by creating '~/.bundle/config' containing

    ---
    BUNDLE_PATH: "vendor/bundle"
    BUNDLE_BIN: ".bundle/bin"

(The BUNDLE_PATH one is the important one; see 'bundle config --help' for other options.)

As one of the few package mangers, nix can be used without root access.

As you pasted-it, it does not accomplish venv:

  - you still need to change PYTHON_PATH to recognize libs from `libs`
  - packages have bin scripts sometimes that most likely, will be needed by the project

A more proper command: - pip install -t ./libs --install-option="--install-scripts=./bin"

But still, does not solve the PYTHON PATH issue, it won't be solvable because all python cli tools and all scripts in ./bin must be aware of PYTHON_PATH including ./libs

This is what venv does and pip alone cannot easily solve, replicating an entire python environment that is aware of project local pip packages

No, you still don't have:

- ./bin. No commands for you.

- a way to specify your libs to a program not providing a way to set env var.

- isolation from the system stdlib. This will cause subtile bugs.

- a clean pip freeze. No deps listing.

- and hence a lock file.

It solves more than that:

- beginers don't have to understand the whole virtualenv shenanigans. I use pew myself to replace virtualenvwrapper but I will switch to pipenv just to ease the pain of team member joining in.

- it enforces good dependency management practice with the toml file and lock file. This is an issue in almost all project I worked on, including ones from Python experts. We all use only requirements.txt file out of convenience, and never lock.

- it's one tool to do all the packaging stuff. No need for pip and virtualenv and a wrapper. You got one command.

Is that true? His command would evaluate the path at the time which is run, but yours seems to evaluate the path at the time python3.5 is run. Subtle, but very different results.

Arch is the oddball. I'm not aware of anybody else who's made the switch.

Given that they're not mutually compatible except in rare cases, it's a very silly thing to do. You can upgrade GCC with the same name because you know it will handle most of the same input. If you do that with Python you're breaking tons of existing scripts for very close to zero benefit. Why would you do that?

Huh.

https://www.python.org/dev/peps/pep-0394/

Not yet. At least on ubuntu 16.10 python still defaults to `python2`