Re: Dealing with flit -- a simplified packaging of python modules
On Sat, Sep 19, 2015, at 09:36 AM, Barry Warsaw wrote:
> There have been countless attempts at moving the Python packaging
> infrastructure to a declarative syntax over the years. I remember
> talking to
> Tarek at a Pycon *many* years ago about this. Maybe this time it'll
> catch
> on. :)
I think the introduction of wheels makes this goal more practical, as
now there's a defined package format that tools can build, rather than
relying on executing a script at install time. I'm also making the
problem easier using the 80/20 rule: flit doesn't aim to replace all
setup.py Python packaging. It's limited to a single module/package of
pure Python code, which I think accounts for a large majority of what
people do with setup.py.
> flit doesn't build sdists, so I guess the current toolchain which starts
> with
> .orig.tar.gz won't work with flitted packages. The README says:
>
> "People may also want a traditional sdist for other reasons, such as
> Linux
> distro packaging. I hope that these problems will diminsh over time."
>
> I'm not sure which problem you hope will diminish! People wanting
> traditional
> sdists, the problem of Linux distro packaging <wink> or needing sdists
> for
> downstream consumers like Debian.
There are certainly times when I wish distro packaging would focus on
maintaining a much smaller set of core infrastructure packages really
well. Take Jupyter, for instance: as upstream, we feel no investment in
Linux distro packaging of it, and if we're helping people who got it
from apt, we're likely to recommend that they uninstall that and use
Anaconda or pip to install a recent version. I don't think distro
packaging works for user-facing applications, and AFAIK it's not widely
used for web app deployment either.
However, my hope in that sentence was that other packaging will come not
to rely on Python sdists containing a setup.py file. Using sdists for
Debian packaging is already somewhat dubious, because they can contain
generated and bundled files (we do both for Jupyter Notebook sdists).
The way I'd like to see things working is for the canonical source for a
release to be the tag in the VCS. Popular code hosting sites like Github
make the source tree at this tag readily available as a downloadable
tarball, e.g.:
https://github.com/jupyter/testpath/archive/0.2.tar.gz
The source tree contains metadata about the Python package in the repo.
Different tools can use that to build wheels for PyPI, conda packages,
Debian packages, or whatever. Of course, only the first of those is
implemented yet, and it's no doubt more complex to build a .deb package,
but that's where I'd like things to go.
Thomas
Reply to: