[Distutils] What binary formats should we be distributing?

[Marius Gedminas]

On Thu, Nov 27, 2014 at 11:25:41PM +0000, Paul Moore wrote:
> On 27 November 2014 at 17:47, Randy Syring <randy.syring at level12.io> wrote:
> 
> >  pymssql uses Cython and the FreeTDS C library to support connections to
> > Microsoft SQL Server.  We would like to distribute binary packages to ease
> > installation for users.  Our current build matrix looks like this:
> >
> > https://github.com/pymssql/pymssql/wiki/Build-Matrix
> >
> > However, we are trying to cut that down some since, by the time we support
> > 5 versions of python (2.6,2.7,3.2,3.3,3.4), we are having to release 30 and
> > now, since we are considering .msi files, maybe 40 files per release.
> >
> > I'm trying to figure out if there are any downsides to:
> >
> >    - replacing our .exe with .msi (lxml uses .exe, but we noticed Python
> >    itself is shipping .msi files now)
> >     - only shipping wheels and no longer shipping eggs
> >
> > I would also appreciate any other thoughts regarding what kind of binary
> > formats a "responsible" package owner would ship.
> 
> I can only really comment on Windows, but I would say that wheel is
> sufficient there. The longer term intent is that wheel supersedes all of
> the other binary formats as a universal standard. There's a way to go yet,
> so there may be reasons to still ship other formats, but you should be
> looking to phase them out once your users no longer need them.
> 
> I would strongly recommend against msi, as they are not typically useful
> for Python packages. Sure, the Python distribution itself uses msi, but the
> reasons for that are not really applicable to Python packages. The
> bdist_msi format is very rarely used in practice, and that is likely to
> decrease rather than increase. The one proviso that I would make is that
> this is from a hobbyist/open source perspective. I'd guess from the fact
> that you're distributing a SQL Server library that you have a larger than
> average proportion of "corporate" users. In that sort of environment, MSI
> installers may be more useful, as they integrate better with corporate
> deployment tools. But that's not something I can really comment on.
> 
> The wininst (exe) format is probably of limited value, It is of use for
> systems without pip where integration with add/remove programs is useful,
> but such systems are probably rare. But if you want to distribute a
> "standalone installer" format, exe is probably more familiar to Python
> package users than msi. On the downside, it doesn't work with virtualenvs.
> 
> As regards eggs, they are essentially the precursor to wheels as a binary
> distribution format. Users still using easy_install will need eggs (but why
> aren't they using pip these days?). It's possible that older systems such
> as buildout may still need eggs, but I'm not familiar with these systems
> and don't know if they can use wheels instead these days.

Buildout is based on easy_install and doesn't support wheels.  It
supports .egg or, I believe, .exe installers.  I'm not sure about .msi.

If setuptools were to support wheels, buildout would get that support
automatically, AFAIU.  (Why doesn't setuptools support wheels natively?)

Wheel files can be created automatically from .egg/.exe files using
'wheel convert', so supporting both shouldn't be a big hassle and can be
automated.

Marius Gedminas
-- 
2B OR NOT 2B == FF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141128/0bb2fea5/attachment.sig>