5 ms·

Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx

Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx", "pip show xxx", "pip list", "pip uninstall xxx" I'm curious what I've been missing about pip that makes it problematic - I've never used the other tools you mentioned (setuptools/distutils/ez_install) - so I can't comment on them, but, on the flip side, I've never had to use them, so maybe my requirements are somewhat more simple than yours.

sametmax 10y ago
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/ 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 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-proprement/ 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.
- renesd 10y ago
  Nice list of warts.
- schlumpf 10y ago
  This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?
  - daenney 10y ago
    You don't need to install (ana|mini)conda just to get a package manager, would be why I would use Pipenv over Conda. Miniconda alone requires somewhere close to 400MB of space and comes with a whole bunch of extra things I don't need just to manage packages and virtualenvs.
    - kalefranz 10y ago
      The miniconda bootstrap of conda is ~20-30 MB (compressed) depending on platform. It contains only conda and its dependencies, like python and requests. It's how you install conda if you want only conda. The 400 MB number is for the Anaconda Distribution, which is a self contained, single-install, get-all package primarily aimed at scientists and engineers.
    - darkarmani 10y ago
      Don't you mean 45MB windows, and 21 MB OSX? https://repo.continuum.io/miniconda/ https://repo.continuum.io/miniconda/
  - sametmax 10y ago
    pipenv allow you to completly ignore the virtualenv. Like node_packages. It seems a detail, but giving a lot of python and js trainings, I came to realize newcomers needs little help like this.
  - mdeeks 10y ago
Kaizyn 10y ago
Pip is built on top of setuptools/distutils, so you are using them without even knowing it.
- yjftsjthsd-h 10y ago
  Not atypical; I'm pretty sure apt uses dpkg, and dnf and yum use rpm underneath.

sametmax 10y ago

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

renesd 10y ago
Nice list of warts.
schlumpf 10y ago
This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?
- daenney 10y ago
  You don't need to install (ana|mini)conda just to get a package manager, would be why I would use Pipenv over Conda. Miniconda alone requires somewhere close to 400MB of space and comes with a whole bunch of extra things I don't need just to manage packages and virtualenvs.
  - kalefranz 10y ago
    The miniconda bootstrap of conda is ~20-30 MB (compressed) depending on platform. It contains only conda and its dependencies, like python and requests. It's how you install conda if you want only conda. The 400 MB number is for the Anaconda Distribution, which is a self contained, single-install, get-all package primarily aimed at scientists and engineers.
  - darkarmani 10y ago
    Don't you mean 45MB windows, and 21 MB OSX? https://repo.continuum.io/miniconda/ https://repo.continuum.io/miniconda/
- sametmax 10y ago
  pipenv allow you to completly ignore the virtualenv. Like node_packages. It seems a detail, but giving a lot of python and js trainings, I came to realize newcomers needs little help like this.
- mdeeks 10y ago

Kaizyn 10y ago

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

yjftsjthsd-h 10y ago
Not atypical; I'm pretty sure apt uses dpkg, and dnf and yum use rpm underneath.