4 ms·

> PyPI, pip, wheels, and the underlying setuptools machinations are all designed for libraries. Code for developer reuse. Many Python applications seem to disa

> PyPI, pip, wheels, and the underlying setuptools machinations are all designed for libraries. Code for developer reuse. Many Python applications seem to disagree with this point. The one I most recently deployed, Mayan EDMS[0], includes installing the application using pip. On a side note, one thing that's always driven me nuts about having multiple package managers is that they don't talk to each other. If I install a system-wide Python library using pip, the system package manager isn't aware of it and will try to install the vendor-provided, and usually older, version to satisfy a dependency. Likewise, there's no way for pip to ask the underlying OS to install some dependencies - just look at the packages you have to install to get Mayan EDMS running. This isn't as simple as asking for a given package name, you have to ask for the name that the underlying OS/package manager knows that package by. For example, "apt-get install postgresql" might suffice for Debian, but on FreeBSD you might need something like "cd /usr/ports/database/postgresql96; make; make install". I'm not singling out Mayan EDMS here, it just happens to be the most recent bigish Python application I've installed so most of what I went through is fresh in my mind. [0] https://mayan.readthedocs.io/en/latest/topics/deploying.html#os-bare-metal-method https://mayan.readthedocs.io/en/latest/topics/deploying.html...

mhashemi 9y ago
Absolutely! The post mentions a little bit how pip is definitely used for distributing command-line applications, from fab to pex to ansible. So much so that pipsi[0] is a thing. Even the tiny static site generator used to generate the post is a CLI app that leans on PyPI for distribution[1]. The origins and designs for the tools listed are primarily for libraries. Entrypoints[2] and other features came much later. Use of these techniques is overextended when developer distribute nontrivial code on PyPI with a non-developer audience. People get a buggy install and conclude that Python packaging is the problem :) As for the package manager crosstalk, I feel you. That's definitely a source of the demand for tools that create self-contained artifacts. [0]: https://github.com/mitsuhiko/pipsi https://github.com/mitsuhiko/pipsi [1]: https://pypi.python.org/pypi/chert https://pypi.python.org/pypi/chert [2]: http://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation http://setuptools.readthedocs.io/en/latest/setuptools.html#a...
PopsiclePete 9y ago
Python/Ruby/Node all suffer from this - the OS stubbornly thinks it knows what's best. Here's what I do. 1. Ignore the OS when developing - let it manage its own dependencies for its own Python - fine. I use pyenv/rbenv/nvm to install my own dev. version of <language> and use isolated virtual environments for developing. 2. Deploy using Docker - again - ignoring whatever the OS has installed.
- viraptor 9y ago
  That's kind of by design. You're supposed to develop with virtualenv. Then, if someone packages your app for inclusion into the distro, it's on them to package the compatible dependencies and your app. (I mean, it would be nice if the devs helped here, but that's what distribution maintainers are for) Not sure why you need docker though. It's fairly easy to distribute python libraries in a simple tarball.
  - brianwawok 9y ago
    If you want to do something like kubernetes you need to slap your python tar into a docker image.
    - viraptor 9y ago
      Not sure I understand your point. Kubernetes is a service for managing containers. If you want kubernetes, of course you'll need containers of some sort. But not all apps need multi-host orchestration.

mhashemi 9y ago

Absolutely! The post mentions a little bit how pip is definitely used for distributing command-line applications, from fab to pex to ansible. So much so that pipsi[0] is a thing. Even the tiny static site generator used to generate the post is a CLI app that leans on PyPI for distribution[1]. The origins and designs for the tools listed are primarily for libraries. Entrypoints[2] and other features came much later. Use of these techniques is overextended when developer distribute nontrivial code on PyPI with a non-developer audience. People get a buggy install and conclude that Python packaging is the problem :) As for the package manager crosstalk, I feel you. That's definitely a source of the demand for tools that create self-contained artifacts. [0]: https://github.com/mitsuhiko/pipsi https://github.com/mitsuhiko/pipsi [1]: https://pypi.python.org/pypi/chert https://pypi.python.org/pypi/chert [2]: http://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation http://setuptools.readthedocs.io/en/latest/setuptools.html#a...

PopsiclePete 9y ago

Python/Ruby/Node all suffer from this - the OS stubbornly thinks it knows what's best. Here's what I do. 1. Ignore the OS when developing - let it manage its own dependencies for its own Python - fine. I use pyenv/rbenv/nvm to install my own dev. version of <language> and use isolated virtual environments for developing. 2. Deploy using Docker - again - ignoring whatever the OS has installed.

viraptor 9y ago
That's kind of by design. You're supposed to develop with virtualenv. Then, if someone packages your app for inclusion into the distro, it's on them to package the compatible dependencies and your app. (I mean, it would be nice if the devs helped here, but that's what distribution maintainers are for) Not sure why you need docker though. It's fairly easy to distribute python libraries in a simple tarball.
- brianwawok 9y ago
  If you want to do something like kubernetes you need to slap your python tar into a docker image.
  - viraptor 9y ago
    Not sure I understand your point. Kubernetes is a service for managing containers. If you want kubernetes, of course you'll need containers of some sort. But not all apps need multi-host orchestration.