Re: Dealing with flit -- a simplified packaging of python modules
On September 25, 2015 at 8:21:39 PM, Ben Finney (ben+debian@benfinney.id.au) wrote:
> Donald Stufft writes:
>
> > On September 25, 2015 at 7:24:30 PM, Paul Wise (pabs@debian.org) wrote:
> > > Why are end users using source packages instead of binary packages
> > > and then complaining that the source tarballs aren't ready-to-run
> > > binary packages?
> >
> > Because the way Python packaging currently is and historically has
> > been, binary packages are not something that is widely available or
> > viable.
>
> So, commendable effort has gone toward making that problem reduce,
> perhaps eventually to go away. Congratulations are deserved for getting
> us this far, and thanks for continuing to push for feasible binary
> distributions of Python packages on all supported OSen.
>
> It seems reasonable, then, to also put effort toward making source
> distributions more targeted toward being bundles of the released
> *source* for the project version, and reducing the justification for
> bundling non-source files in the source distribution.
I think distutils/setuptools is to blame for a lot of this, they don't make it
easy to have generated files that aren't either compiled C code or py(c|o).
Ideally in the future distutils/setuptools will no longer be special (except as
a historical and legacy fallback) and we'll have something far more pluggable
in the future. This will ideally make it a lot easier and sane to have custom
build steps that create other generated files as part of the building of a
package.
>
> Can we expect the value of “but people expect non-source stuff bundled
> in the source distrubution” to diminish, as some kind of objection to
> making proper source distributions?
It's certainly a goal of mine that we move as much of the upstream Python
packaging onto binary packages so that most people are not installing from
sdists or really, "installing" from an sdist being an outdated concept and
long term, the only thing we do with an sdist is turn it into a binary package,
even if that build step is taken on the end user's computer. I of course, can't
speak to everyone so it would not surprise me if some people simply will never
be willing to not distributed generated files as part of their sdist.
I suspect this to be a long road though, and certainly the nature of *nix makes
it harder on us, since it's hard to make a binary package that works for say,
all of Linux due to ABI problems and such. The more cases where ``pip install``
has end users pulling from a sdist, the more resistence I suspect you'll find
from authors to making sdist have more complicated build steps.
I suspect you'll have an easier time convinving authors of pure Python things
that include some generated files (translations, js, whatever) to rely entirely
on wheels than you will have convincing authors of Python things that include
some C or other compiled code that precludes universal(ish) Wheels.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Reply to: