Re: PyPI source or github source?
On Sun, 2017-03-12 at 10:53 +0800, Paul Wise wrote:
> On Sun, Mar 12, 2017 at 10:19 AM, Brian May wrote:
>
> > Sure, you could argue that PyPI source packages should contain
> > everything the github package does. In fact there is a PyPI tool to help
> > get the MANIFEST.in correct for such purposes -
> > https://pypi.python.org/pypi/check-manifest
>
> Anyone interested in packaging this?
There is an RFP filed for it [1]. I could have a look at it. I recently
found out that this tool is listed in the PyPA sample project [2].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734117
[2] https://github.com/pypa/sampleproject/blob/master/setup.py
> > Unfortunately, github releases cannot (AFAIK) easily be signed, unless
> > you retrieve signed git tags directly from git (which is not supported
> > by uscan AFAIK). Would be good if gbp buildpackage supported signing git
> > tags, I don't think it does either.
>
> uscan does support git but doesn't check OpenPGP signatures on tags.
> It would probably be easy to add that, please file a bug about it.
>
> > * Do we consider signed git tags / commits secure, considering they are
> > based on SHA1?
>
> Better than having unsigned tags/commits.
>
> > * Is there any point having signed PyPI releases when (very likely) the
> > underlying upstream git repository has no signatures?
>
> Yes, presumably the PyPI releases are built from the author's copy of
> the git repository, rather than directly from the online repository,
> hopefully they have verified all commits they pulled into it.
>
> > * Is there any point having signed PyPI releases when (very likely) the
> > public key is stored in an insecure DPMT respository on
> > git.debian.org?
>
> Yes, it is also stored in immutable places like the archive and snapshot.d.o.
My personal gripe with GitHub releases is that they are often full of
unwanted stuff, such as various CI config files (travis, circle,
appveyor...), test config files (pytest, nose, tox...), conda scripts,
GitHub files (.github/ directory) and whatnot. They are not harmful but
it is clutter the distributed sources could definitely live without.
On the other hand, I have seen very few pieces of software which had a
*comprehensive* MANIFEST.in for generating a tarball suitable for
packaging. The file is often either absent, or missing inclusion of the
docs, tests, change log or license files. Upstream is usually receptive
in providing "better" source tarballs, but I have had some developers
taking an aggressive stance towards keeping the PyPI tarball as minimal
as possible in the past.
Ghis
Reply to: