Announcing Pipenv

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.

I find tools like virtualenvwrapper and this one from Kenneth tend to solve issues I don't really have. A little bit of repetitive typing here and there is ok to burn knowledge into my mind; and less leaky abstractions I have to deal with, the better.

- 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.

We just use a directory where we keep our dependencies. It's a matter of:

    mkdir libs
    pip install -t libs 
    # then to run
    PYTHONPATH=libs python app.py