2

If I create a FOSS command-line utility (i.e. an application rather than a library) and I want to distribute it as a package for convenient installation, is it better practice to do this via:

NB. If you believe there is no generally correct practice but rather that there are particular circumstances under which one or the other approach is clearly best, then what are these circumstances?

2 Answers2

1

According to this blog entry, the main reasons you should

NEVER install a Python module system-wide with setuptools/ez_setup on your Debian system

are

  1. that you can have different versions of the same Python modules in different installation paths (installed via easy_install and aptitude)

  2. there is no easy_uninstall. (However, pip seems to be able to do this: How do I remove packages installed with Python's easy_install?)

The same applies to a CLI tool, which also is a (Python) module of sorts.

Of course, packaging for easy_install requires less work than packaging for all the system package managers out there. But why don't you package your tool with easy_install and ask somebody who is familiar with packaging for the particular targets for help? (For Debian, you can try sending an e-mail to submit@bugs.debian.org with a subject that starts with "[needs-packaging]".)

Let me tell only from my limited experience as user -- Python and Debian/Ubuntu. When I finally switched from Windows to Ubuntu, one of the main reasons was the painless installation of almost all software that has been packaged for Debian. One of the questions during the first period of transition were:

"What's the most recent multi-way diff tool? OK, there's meld and diffuse. Let's see..."

sudo apt-get install meld diffuse

"OK. And this clipboard manager was called Parcellite?"

sudo apt-get install parcellite

"I love Task Coach. Do they have it?"

sudo apt-get install taskcoach

"Now why is svn not installed out of the box?"

sudo apt-get install svn
... (some error)
apt-file search svn
... (tl;dr)
apt-file search svn | grep /svn$
sudo apt-get install subversion

So much for the convenience of packaging. Note that at least the first two tools mentioned are pure Python tools, but I don't care -- the system package manager does everything for me. Perhaps I would have even installed them using easy_install if that was the only option, but then I could have been made aware of the risks of systemwide installations using easy_install, and would have dropped it.

Community
  • 1
  • 1
krlmlr
  • 22,030
  • 13
  • 107
  • 191
  • I'm grateful for your answer, but it seems to be a bit one-sided and to be based on just one source, which makes at least one criticism that isn't really valid anymore. –  Jun 29 '12 at 05:50
  • @sampablokuper: The issue with different versions in different paths still applies. – krlmlr Jun 29 '12 at 05:57
  • Even so, I'm concerned not to attribute a particular application-level package manager's shortcomings to application-level package managers in general. I think it's only if they (nearly) all share the shortcomings that the shortcomings are relevant to my question. –  Jun 29 '12 at 06:10
0

It seems to me that the procedure followed in the case of applications whose users are happy with the way they're distributed, is roughly as follows:

enter image description here

Take, for example:

  • Bundler: written in Ruby and useful to Ruby developers; distributed via application-level package.
  • fwknop: written in Perl (originally, at least) and useful to end-users; distributed via systems-level packages/installers.
  • Pandoc: written in Haskell and may be useful to Haskell developers in the course of developing Haskell applications, but also useful to others; distributed both via application-level and via systems-level packages.

There are probably better examples than these. Also, my conclusions so far are just observational ones: I haven't found a reference laying out this decision flow explicitly. As such, I'd welcome a more comprehensive answer.

NB. The code for the flowchart is online, in case you'd like to adapt it for your answer. To be able to use it, you'll need a working LaTeX installation.