[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Go (golang) packaging, part 2

On Feb 06, 2013, at 03:26 PM, Roland Mas wrote:

>I can only speak about Python and Perl, but I don't remember *ever* having
>been told to use their deployment system instead of the packaged versions of
>the interpreter and modules.  The closest I've seen is something like "if
>you're running CentOS or RHEL, then you'll need this plethora of modules that
>are not packaged, so please use our language-specific system to install them

Speaking with many hats on, I think Debian Python has done a very admirable
job of integrating the Python ecosystem with Debian.

It's never going to be perfect, and there are certainly difficult outliers,
but in most cases, things work pretty well.  OTOH, Python itself has several
strategies for dealing with difficult situations, with probably the most
notable being virtualenv (and upstream's built-in venv in Python 3.3+).  You
can even mix and match, i.e. if some Debian packaged versions are fine but you
need one or two missing or out-of-date packages from the Cheeseshop, you can
`virtualenv --site-system-packages` that generally works pretty well.

Where things get tricky is if you have multiple applications that need
different versions of its dependencies.  Say Debian has python-foo 1.2 which
application Bar needs, but application Baz needs python-foo 2.0.  Despite
years of discussion, in Debian, Ubuntu, and upstream, we really don't have a
good multi-version story.  I think that's forgivable though because it's a
Really Hard Problem and nobody's stepped up to pay a team of 5 gurus for the
25 man years of non-stop work it would probably take to solve (both
technically and socially ;).  This problem isn't particularly limited to

I'm also encouraged by the albeit slow work on upstream packaging technology
(PEPs and code) to help improve the overall packaging story.  I had many
discussions with various packaging folks, and good developers from Fedora and
other distros, about ways to make it easier to integrate PyPI packaging with
distros, Linux-based or otherwise.  I thought we'd made a lot of good
progress, but some of the drivers moved on to other things.  I'm hoping Nick
Coghlan's efforts at Pycon 2013 can help motivate a revival of this work[1].



Attachment: signature.asc
Description: PGP signature

Reply to: