Re: PyPI source or github source?

2017-03-18 Thread Brian May
Thomas Goirand writes: > IMO, upstream are right that the PyPi releases should be minimal. They > are, from my view point, a binary release, not a source release. To go against this, often PyPI releases contain *.pyc files. Looking at django-filter 0.13.0 right now. -- Brian

Re: PyPI source or github source?

2017-03-14 Thread Thomas Goirand
On 03/13/2017 10:40 PM, Ghislain Vaillant wrote: > Do you get rid of the useless dotfiles (gitignore, ci settings, tox...) > or leave them alone then? It is a battle that needs a lot of efforts for not so many rewards, so I just leave them alone. However, I could probably just add a few

Re: PyPI source or github source?

2017-03-14 Thread Brian May
Ghislain Vaillant writes: > Do you get rid of the useless dotfiles (gitignore, ci settings, tox...) > or leave them alone then? So far .. they have never caused any problems. So leave them as is. Think you can leave tox, that can still be useful. -- Brian May

Re: PyPI source or github source?

2017-03-13 Thread Ghislain Vaillant
On Tue, 2017-03-14 at 08:32 +1100, Brian May wrote: > Scott Kitterman writes: > > > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > > so > > that the sdist is complete when I point out the issue. > > I have had some people who do argue that

Re: PyPI source or github source?

2017-03-13 Thread Brian May
Scott Kitterman writes: > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > so > that the sdist is complete when I point out the issue. I have had some people who do argue that sdist is an installation format, not a source format - if you want

Re: PyPI source or github source?

2017-03-13 Thread Ole Streicher
Brian May writes: > Should we be using PyPI as our source of packages? Or github? I already had packages that use a helper to generate the version information from the git repository, and therefore need the git metadata to build from source. I could solve this with a "fake"

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 14, 2017, at 08:16 AM, Brian May wrote: >I just found another one: python-ledger. Unfortunately in this case, >Python packages are also bundled with the C code (libraries and client). Not entirely relevant, but pyparted also contained C code, but its mainline does support Python 3.

Re: PyPI source or github source?

2017-03-13 Thread Scott Kitterman
On Monday, March 13, 2017 05:55:32 PM Thomas Goirand wrote: > On 03/12/2017 11:34 AM, Ghislain Vaillant wrote: > > 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

Re: PyPI source or github source?

2017-03-13 Thread Brian May
Barry Warsaw writes: > I've so far only encountered one package that releases on GitHub and not PyPI: > pyparted. And I've filed an upstream bug about that. I just found another one: python-ledger. Unfortunately in this case, Python packages are also bundled with the C code

Re: PyPI source or github source?

2017-03-13 Thread Thomas Goirand
On 03/13/2017 06:50 PM, Barry Warsaw wrote: > Wheels should be considered a binary release, but tarballs should still be > considered the canonical source release. For the case of PyPi releases, they are to be used using "pip install", which is what makes me think they are designed for this use

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 13, 2017, at 05:55 PM, Thomas Goirand wrote: >IMO, upstream are right that the PyPi releases should be minimal. They >are, from my view point, a binary release, not a source release. Wheels should be considered a binary release, but tarballs should still be considered the canonical source

Re: PyPI source or github source?

2017-03-13 Thread Jeremy Stanley
On 2017-03-13 17:55:32 +0100 (+0100), Thomas Goirand wrote: [...] > IMO, upstream are right that the PyPi releases should be minimal. They > are, from my view point, a binary release, not a source release. > > It makes a lot of sense to therefore use the git repository, which is > what I've been

Re: PyPI source or github source?

2017-03-13 Thread Thomas Goirand
On 03/12/2017 11:34 AM, Ghislain Vaillant wrote: > 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

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 12, 2017, at 01:19 PM, Brian May wrote: >Should we be using PyPI as our source of packages? Or github? PyPI for two reasons: not every developer uses git, and even those that do may not use GitHub. I've so far only encountered one package that releases on GitHub and not PyPI: pypar

Re: PyPI source or github source?

2017-03-12 Thread Ghislain Vaillant
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

Re: PyPI source or github source?

2017-03-11 Thread Paul Wise
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

PyPI source or github source?

2017-03-11 Thread Brian May
Ben Finney writes: > Debian's UScan has the ability to find, download, and verify the GnuPG > signature for a package source release. Lintian will remind the > maintainer if a Debian source package is not taking advantage of this. A related issue is: Should we be using PyPI