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
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
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
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
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
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"
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.
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo