How can a Debian package install Python modules from PyPI

16,820

Solution 1

I've spoken with some maintainers at the Debian IRC channel irc://irc.debian.org#debian-mentors, asking for the exact same thing, and the general consensus was:

Solution #1:

Integrating dependencies in your package by copying their source files over as a single codebase is very frowned upon. It would defeat the purpose of a packaging system that handles dependencies, updates, versioning, etc.

Solution #3:

Downloading non-debian packages on-the-fly when installing a binary (.deb) is a serious security risk, definitely a no-no. You wouldn't even be able to inspect the dependencies by extracting the deb, because they are downloaded and installed at install time. It's an approach that completely bypass the repositories system. No concerned user would be happy with a package that, behind the scenes (and as root, remember!), downloads additional untrusted software from untrusted sources. Yes, that would require fiddling with DEBIAN/postinst (or preinst) and issuing a wget (or, in your case, pip install), and that is the approach taken by Flash, Oracle Java, Steam and others. But that is proprietary, closed source software, so their security is none anyway.

Solution #1.5:

You didn't mention it, but you could integrate the dependencies only at build time, ie, in the source package (the .orig.tar.gz, .debian.tar.gz, .dsc triad), by downloading from PyPi when creating the "binary" package (the .deb). The instructions for the pip install would go into debian/rules (notice the lowercase debian, as opposed to the binary package), and would be executed when you issue debuild or dpkg-buildpackage.

This is a middle-ground between #1 and #3. It mitigates (but not solve!) some of the issues of #3: at least you can inspect the final product, and the .deb would not require internet access at install time. All the risks and burdens are transferred from final user to the package maintainer. But, has the same problems as #1, as it bypasses most of the packaging system infrastructure. Afterall, handling dependencies (versions, updates, requirements, conflicts) is why dpkg/aptwas created in the first place! :)

Solution #2:

The One True Right Way™. You create debian packages for your dependencies, list them as requirements in your package, and ship all the .debs or source packages.

From there, you have a number of options:

  • Submit the source packages, both your software and its dependencies, for inclusion to Debian. If accepted, they would be automatically available to all Debian users, including all derivatives like Ubuntu.

  • Upload the source packages to Launchpad, thus creating a PPA that any Ubuntu user (and its derivatives like Linux Mint) could easily add and install

  • Host your own debian repository in your website, that users from any Debian-based system could add to their /etc/apt/sources.list.d and use the apt infrastructure to download, install and keep updated, (like the above!)

  • Host the .deb files for direct download and install. No apt or automatic updates involved thought.

As for how to package your PyPi dependencies (and your python software too!), there are a number of tools and references that make the process easy:

  • stdeb, as you mentioned. Oldie and goodie.

  • Pybuild, a new, amazing tool from Debian that supersedes stdeb.

And many useful references:

Need help? Check those out:

Solution 2

There is pypi2deb to get a package from pypi and make it into a deb package.

Solution 3

I think you just need to add the relevant command line code to the postinst script in the .deb package. Found in this answer, more details at the official debian guide.

Share:
16,820

Related videos on Youtube

andri_ch
Author by

andri_ch

Updated on September 18, 2022

Comments

  • andri_ch
    andri_ch almost 2 years

    This question tries to complement this one . I have a python app which uses third party modules from PyPI. I want to package my app into a debian package, but don't know how to handle python dependencies which are not in debian/ubuntu repositories(packed as debian packages too)

    Solution #1:
    build the modules from PyPI right into my debian package.

    Solution #2:
    create debian packages for all PyPI modules I need using stdeb and add them to debian/ubuntu repositories.

    I actually need a Solution #3 because I want to install PyPI dependencies when I install my debian package, preferably into a virtualenv!

    What would be Solution #3? Do I need to tweak DEBIAN/preinst maintainer script?

    • Jonathan
      Jonathan almost 11 years
      Can you describe why you need to create a Debian package? Does your Python app need non-Python resources?
    • andri_ch
      andri_ch almost 11 years
      @Jonathan I want users to be able to install my app from Ubuntu Software Center. I think I need a *.deb for that. My Python app doesn't need non-Python resources, just third-party python modules.
    • MestreLion
      MestreLion almost 10 years
      @Jonathan Debian packages are the standard installation method in Ubuntu. One can easily distribute a .deb file, or setup a private repository, or a PPA in Launchpad.
  • SevakPrime
    SevakPrime over 8 years
    This doesn't answer the OP's question. The question is how to have a Debian package install a Python package from PyPi so that an 'apt-get <custom-package>' or 'dpkg -i <custom-package>' would pull python dependencies from PyPi.
  • Sérgio
    Sérgio over 8 years
    They don't , is like cpan in perl , if you have in repositories , you may install with apt-get , if not you may install with pip , the difference should be that pip install in /usr/local, but maybe it will be better delete my answer .
  • SevakPrime
    SevakPrime over 8 years
    Your comment provides an appropriate answer to the OP's question. You should put that comment in your answer to be up-voted. (For example, see MestreLion's answer.) As is, your answer doesn't answer the OP's question.
  • zezollo
    zezollo about 4 years
    Unfortunately at the moment it doesn't look actively developed anymore.