[Distutils] Distributing Python-programs to Ubuntu users

[Ben Finney]

Olof Bjarnason <olof.bjarnason at gmail.com> writes:

> So your proposed course of action is
>
> 1) learn distutils + setup.py ecosystem

Yes, this is essential. It's also, fortunately, not a very large topic
<URL:http://docs.python.org/distutils/>.

It is, unfortunately, rather flaky (you can read the archives of this
forum to see some of the hair-pulling it causes), and it gets more
complex in the non-core third-party extensions that have arisen to
address some of the Distutils shortcomings (see e.g. Setuptools), but
first things first: learn and use Distutils, the current standard
distribution system for Python software.

> 2) concentrate on application itself, not packaging

Yes. With a good program, distributed with the whole work under
widely-understood free software license terms (e.g. GNU GPL) and
published on PyPI <URL:http://pypi.python.org/pypi/> as an ‘sdist’,
packagers will come to make OS-specific binary packages.

> 3) make some kind of fast-feedback system to achieve (2)
>
> I can see a conflict between (3) and (2) - since packaging is not
> under my control all feedback will be severely delayed, from users of
> my app. What is a good approach to minimize time from release to
> packaging?

The early adopters of your software will be those who are not afraid of
building it themselves from an ‘sdist’. That population will be where
the OS-specific package maintainers will come from. So, be responsive to
your early adopters, and set up a distributed version control system and
bug tracking system (at e.g. Bitbucket or Launchpad you can have both in
the same place).

Those early adopters may well provide patches against your code (which
is why having a public distributed VCS is important), and will want to
be able to track their reported issues over time (which is why an
organised bug tracking system is important), as the issues are exposed
and dealt with.

If you continue to make releases that incorporate those changes that
make sense for distribution to all users, that seems the best fast
feedback. I don't see a conflict between your focus on being the core
developer of the actual work, and others's focus on the OS-specific
issues that arise. With each party focussing their attention where their
skills are, and with the appropriate workflow tools in place, it's about
as rapid as mere human programmers can hope for.

-- 
 \          “All good things are cheap; all bad are very dear.” —Henry |
  `\                                                     David Thoreau |
_o__)                                                                  |
Ben Finney