3 ms·

Highly recommend FPM for creating packages (deb, rpm, osx .pkg, tar) from gems, python modules, and pears. https://github.com/jordansissel/fpm https://github.c

by Cieplak 11y ago

Highly recommend FPM for creating packages (deb, rpm, osx .pkg, tar) from gems, python modules, and pears. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

jlees 11y ago
That seems like a neat tool. I wonder if you could combine it with the sandboxing that dh-virtualenv provides to get the best of both worlds?
- rhelmer 11y ago
  I've used fpm to make rpm and deb packages that simply include a virtualenv, it works ok. One of the significant tradeoffs to this approach is you lose the carefully-crafted tree-of-dependencies that the distros favor, so it makes the package pretty much automatically unacceptable to package maintainers. However, being able to have install instructions that amount to "yum/apt-get install <package>" is pretty great. I am hoping for an app/container convergence at some point, but we might need to drop the fine-grained dependency dream and have them be more self-contained, like Mac OS X apps.
  - vacri 11y ago
    FPM is written as an in-house solution only. It's not intended to be used for making packages for official distro repositories for third-party users to pick up, and they suggest you use the distro-specified methods for those.
- amatix 11y ago
  we use fpm & something like dh-virtualenv along exactly those lines. Helps us manage a complex mix of native/system-level dependencies (non-python) as well as python packages. We also incorporate a set of meta packages which means we can have multiple codebase versions installed and switch the "active" one by installing the right version of the meta-package. There's also meta-packages for each service running off the same codebase, which deals with starting/stopping/etc.
zobzu 11y ago
fpm is cool - very cool. that said it wont create proper spec files and friends, thus its harder to maintain the packages properly. also they usually ont get accepted upstream due to that. that said, for python files and simple packages it works well enough!
daurnimator 11y ago
Rather than such a blunt tool like fpm, if you're deploying only python, look to something like py2deb: https://github.com/paylogic/py2deb https://github.com/paylogic/py2deb
- mixmastamyk 11y ago
  How does this compare with the "dh-virtualenv" tool recommended by the article? Edit: found https://py2deb.readthedocs.org/en/latest/comparisons.html https://py2deb.readthedocs.org/en/latest/comparisons.html
  - daurnimator 11y ago
    https://py2deb.readthedocs.org/en/latest/comparisons.html#notable-differences-with-dh-virtualenv https://py2deb.readthedocs.org/en/latest/comparisons.html#no...

by Cieplak 11y ago

Highly recommend FPM for creating packages (deb, rpm, osx .pkg, tar) from gems, python modules, and pears. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

jlees 11y ago

That seems like a neat tool. I wonder if you could combine it with the sandboxing that dh-virtualenv provides to get the best of both worlds?

rhelmer 11y ago
I've used fpm to make rpm and deb packages that simply include a virtualenv, it works ok. One of the significant tradeoffs to this approach is you lose the carefully-crafted tree-of-dependencies that the distros favor, so it makes the package pretty much automatically unacceptable to package maintainers. However, being able to have install instructions that amount to "yum/apt-get install <package>" is pretty great. I am hoping for an app/container convergence at some point, but we might need to drop the fine-grained dependency dream and have them be more self-contained, like Mac OS X apps.
- vacri 11y ago
  FPM is written as an in-house solution only. It's not intended to be used for making packages for official distro repositories for third-party users to pick up, and they suggest you use the distro-specified methods for those.
amatix 11y ago
we use fpm & something like dh-virtualenv along exactly those lines. Helps us manage a complex mix of native/system-level dependencies (non-python) as well as python packages. We also incorporate a set of meta packages which means we can have multiple codebase versions installed and switch the "active" one by installing the right version of the meta-package. There's also meta-packages for each service running off the same codebase, which deals with starting/stopping/etc.

zobzu 11y ago

fpm is cool - very cool. that said it wont create proper spec files and friends, thus its harder to maintain the packages properly. also they usually ont get accepted upstream due to that. that said, for python files and simple packages it works well enough!

daurnimator 11y ago

Rather than such a blunt tool like fpm, if you're deploying only python, look to something like py2deb: https://github.com/paylogic/py2deb https://github.com/paylogic/py2deb

mixmastamyk 11y ago
How does this compare with the "dh-virtualenv" tool recommended by the article? Edit: found https://py2deb.readthedocs.org/en/latest/comparisons.html https://py2deb.readthedocs.org/en/latest/comparisons.html
- daurnimator 11y ago
  https://py2deb.readthedocs.org/en/latest/comparisons.html#notable-differences-with-dh-virtualenv https://py2deb.readthedocs.org/en/latest/comparisons.html#no...