Bug#834866: ITP: python-whitenoise -- static file serving for WSGI applications
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: python-whitenoise Version : 3.2.1 Upstream Author : David Evans * URL : http://whitenoise.evans.io * License : MIT/Expat Programming Lang: Python Description : static file serving for WSGI applications With a couple of lines of config, WhiteNoise allows your web app to serve its own static files, making it a self-contained unit that can be deployed anywhere without relying on nginx, Amazon S3 or any other external service. This is specially useful if you want to deploy a WSGI application in an application container (e.g. docker). I plan to import this package into the Debian Python Modules Team repositories, even though I don't plan to get myself deeply involved with the team. I will subscribe to this specific package through the package tracker. signature.asc Description: PGP signature
Re: Bug#834768: RFS: codicefiscale/0.9-1
On Fri, Aug 19, 2016 at 10:47:37PM +0200, Elena ``of Valhalla'' wrote: > On 2016-08-18 at 22:27:42 +, Mattia Rizzolo wrote: > > * Files-Excluded in d/copyright doesn't list all the files that are > > removed (at least according to `git diff --stat > > upstream/0.9..upstream/0.9+ds0`) > > besides, wrapping that list might not be a bad idea > > Uhm, I used uscan to remove the files, so nothing that wasn't listed was > removed. > > Do you mean that I should explicitely list all of the content of the > directory ``codicefiscale.egg-info``, instead of just listing the > directory? No, it just means that I rashed too much at reviewing it last night and was already sleeping. I didn't notice all those files where inside a directory -.-' > > * why do you disable the tests? (a comment on d/rules might not be a > > bad idea here either) > > + I see setup.py lists non-existant tests, if that's the issue maybe > > you can get that tests= arg removed (or the actual tests included) > > upstream? > > That's exactly the issue, I've added a comment with a pointer to > https://github.com/ema/pycodicefiscale/issues/6 The project doesn't strike me as very active, but thanks :) > > * just quickly skimming over the README, I think it would make sense to > > include in the binaries, as it provides quick documentation (I think) > > yes, it does, you're right (added in git) You did this: diff --git a/debian/docs b/debian/docs new file mode 100644 index 000..a1320b1 --- /dev/null +++ b/debian/docs @@ -0,0 +1 @@ +README.rst This is not going to do what you expect, check both the produced binaries ;) (`debc` right after having built the package is handy for that, I run it in a pbuilder hook for example) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#834768: RFS: codicefiscale/0.9-1
On 2016-08-18 at 22:27:42 +, Mattia Rizzolo wrote:
> FYI: no need to explicitly CC d-mentors@, RFSes are somehow sent there
> anyway.
ack
> This is DPMT, where the usage of git is mandated, so I expect the git
> repository to match the generated .dsc (hence I'm ignoring mentors here)
it does (hopefully) match, yes
> A few small things I'd like to see:
>
> * you email address in d/copyright
added in git
> * Files-Excluded in d/copyright doesn't list all the files that are
> removed (at least according to `git diff --stat
> upstream/0.9..upstream/0.9+ds0`)
> besides, wrapping that list might not be a bad idea
Uhm, I used uscan to remove the files, so nothing that wasn't listed was
removed.
Do you mean that I should explicitely list all of the content of the
directory ``codicefiscale.egg-info``, instead of just listing the
directory?
> * Also would be nice to see Build-Depends wrap-and-sort'ed
done in git
> * python3-codicefiscale uses ${python:Depends} instead of
> ${python3:Depends}
uooops, fixed in git
> * why do you disable the tests? (a comment on d/rules might not be a
> bad idea here either)
> + I see setup.py lists non-existant tests, if that's the issue maybe
> you can get that tests= arg removed (or the actual tests included)
> upstream?
That's exactly the issue, I've added a comment with a pointer to
https://github.com/ema/pycodicefiscale/issues/6
> * in d/watch, you dversionmangle '.ds0' away, but you're using '+ds0'
> actually, so it's not actually mangling anything
I hate single character typos, fixed in git (it appeared to work in
practice, but only because of versions ordering)
> * just quickly skimming over the README, I think it would make sense to
> include in the binaries, as it provides quick documentation (I think)
yes, it does, you're right (added in git)
--
Elena ``of Valhalla''
Re: on keep providing python 2 packages
Hi Sandro, On Fri, Aug 19, 2016 at 11:49:25AM +0100, Sandro Tosi wrote: > > For example, I have a module (which supports both Python 2 and 3), but > > the only user of this module is an app (which is Python 3 only). > > then this should be an internal module, installed in /usr/share/ > and not importable via python -c "import " It was initially private, but then was split out into a separate module because it can be potentially useful for others. Since that, some third party projects are using it, but they are all Python 3 AFAIK (module in question is pymarkups). > i think we have to support python2 and python3 at the best we can, as > we mandate to have py3k packages > (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html) > i think we should extend the same level of support to python2, until > it will be decided to drop that stack completely How about at least replacing “must” with “should” in the proposed wording? -- Dmitry Shachnev signature.asc Description: PGP signature
Re: on keep providing python 2 packages
On Aug 19, 2016, at 08:19 AM, Sandro Tosi wrote: >I got a feeling we are somehow discouraging the introduction of >python2 package in unstable (it was also discussed at the BoF). Hi Sandro, Just to clarify my own opinion, for *libraries* which upstream supports both Python 2 and Python 3, we should provide both in Debian. It's also easy, so why not? :) I think we should discourage libraries where upstream only provides Python 2 versions, by trying to find bilingual alternatives. Sometimes this is unavoidable though. For *applications* which support both Python 2 and 3, we want to install them only as Python 3 applications, unless there's some overriding reason why we need to provide them for both. That gets into the ugly `nose2-3` situation, so let's really try to avoid that, and encourage `$python -m` style invocation where possible. Now let's talk about libraries for PyPy and Jython. :) Cheers, -Barry
Re: on keep providing python 2 packages
On Fri, Aug 19, 2016 at 11:42 AM, Dmitry Shachnev wrote: > Hi all, > > On Fri, Aug 19, 2016 at 08:19:46AM +0100, Sandro Tosi wrote: >> does anyone else agrees with this view? should we clarify that, when >> available, python2 modules must be provided (along with their py3k)? > > I disagree with the “must” wording. i should have probably specified public modules > For example, I have a module (which supports both Python 2 and 3), but > the only user of this module is an app (which is Python 3 only). then this should be an internal module, installed in /usr/share/ and not importable via python -c "import " > > What’s the point of shipping the Python 2 version of that module then? > > In my opinion, we should neither encourage nor discourage shipping the > Python 2 version, and let the maintainer make the decision. leaving the decision to the maintainer for public modules means we'll have py3k-only packages leaving python2 without a usable module, and if you need one then you file a bug, you wait for the maintainer to act on it, maybe you need it in stable and you have to backport/ask for it. i think we have to support python2 and python3 at the best we can, as we mandate to have py3k packages (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html) i think we should extend the same level of support to python2, until it will be decided to drop that stack completely -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: on keep providing python 2 packages
Hi all, On Fri, Aug 19, 2016 at 08:19:46AM +0100, Sandro Tosi wrote: > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? I disagree with the “must” wording. For example, I have a module (which supports both Python 2 and 3), but the only user of this module is an app (which is Python 3 only). What’s the point of shipping the Python 2 version of that module then? In my opinion, we should neither encourage nor discourage shipping the Python 2 version, and let the maintainer make the decision. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Bug#834809: dh-python: requires.txt versions ignored when writing control
Ok, thank you for the explanation and the quick response :).
Cheers,
Anthony
On Fri, 2016-08-19 at 11:16 +0200, Piotr Ożarowski wrote:
> Control: tags -1 wontfix
>
> > I've been using dh-python to build a package and I've had to add a version
> > dependency in my setup.py (requests >= 2.4.2) but this isn't being picked up
> > and added to the debian/control.
>
> dh_python{2,3} ignores version on purpose. It does more than that, it
> removes recognized dependency from requires.txt so the version is
> ignored later by pkg_resources as well. I'm sure Python guys hate me for that.
>
> There was PEP386, there is PEP440 and plenty of other related PEPs or
> ideas on how to handle versions. The other thing is to put latest or
> unreleased version into install_requires (AKA requires.txt AKA Requires
> header)
> just because that's the version upstream worked with during development.
>
> Until I'm convinced that they finally figured that out and the exception
> is when an upstream project doesn't follow the standard rather than when
> it actually follows it - Debian maintainer will have to confirm that
> upstream is sane WRT versioning to get it copied/translated into Debian
> dependency (and to do that: pydist file with "PEP386" flag has to be
> installed or maintainers have to add versioned build dependency - which
> is my preferred solution as in most cases that version is required for
> tests during build anyway)
>
>
> PS I heard some rumors that PyPI will enforce one of the standards, but
>I don't know the status of that
Re: on keep providing python 2 packages
On 2016-08-19 08:19, Sandro Tosi wrote: > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? Yes.
Re: on keep providing python 2 packages
On Fri, Aug 19, 2016 at 08:19:46 +0100, Sandro Tosi wrote: > I got a feeling we are somehow discouraging the introduction of > python2 package in unstable (it was also discussed at the BoF). > > while i can see why we dont want to introduce new python2-only > package, i feel that just providing a py3k pkg while the module is > also py2 compatible is a disservice to our users: wether we like it or > not, python 2 is the de facto interpreter for python and not having a > module available will not just make everyone switch to py3k (i already > faced it a couple of times already, where i needed a module to extend > an already existing project, and it was not there) > > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? > > apps/scripts are fine being py3k by default, but the underlying > modules has to be provided by for py2 if compatible. > Very much agree. Cheers, Julien
Bug#834809: Info received (Bug#834809: dh-python: requires.txt versions ignored when writing control)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Piotr Ożarowski If you wish to submit further information on this problem, please send it to 834...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 834809: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834809 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#834809: dh-python: requires.txt versions ignored when writing control
Processing control commands: > tags -1 wontfix Bug #834809 [dh-python] dh-python: requires.txt versions ignored when writing control Added tag(s) wontfix. -- 834809: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834809 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#834809: dh-python: requires.txt versions ignored when writing control
Control: tags -1 wontfix
> I've been using dh-python to build a package and I've had to add a version
> dependency in my setup.py (requests >= 2.4.2) but this isn't being picked up
> and added to the debian/control.
dh_python{2,3} ignores version on purpose. It does more than that, it
removes recognized dependency from requires.txt so the version is
ignored later by pkg_resources as well. I'm sure Python guys hate me for that.
There was PEP386, there is PEP440 and plenty of other related PEPs or
ideas on how to handle versions. The other thing is to put latest or
unreleased version into install_requires (AKA requires.txt AKA Requires header)
just because that's the version upstream worked with during development.
Until I'm convinced that they finally figured that out and the exception
is when an upstream project doesn't follow the standard rather than when
it actually follows it - Debian maintainer will have to confirm that
upstream is sane WRT versioning to get it copied/translated into Debian
dependency (and to do that: pydist file with "PEP386" flag has to be
installed or maintainers have to add versioned build dependency - which
is my preferred solution as in most cases that version is required for
tests during build anyway)
PS I heard some rumors that PyPI will enforce one of the standards, but
I don't know the status of that
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: on keep providing python 2 packages
Hi, 2016-08-19 9:19 GMT+02:00 Sandro Tosi : > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? > I agree. Nobody will move to Py3 because Debian doesn't have Py2 module. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: on keep providing python 2 packages
- Mail original - > De: "Sandro Tosi" > À: "debian-python" > Envoyé: Vendredi 19 Août 2016 09:19:46 > Objet: on keep providing python 2 packages > > I got a feeling we are somehow discouraging the introduction of > python2 package in unstable (it was also discussed at the BoF). Don't feel the same. After a try to push some python packages, there was clear indication that python2 only packages are not wanted. But python 2+3 packages were not an issue at all. Python2 is indeed still the default interpreter and as such, if app/lib is compatible, both should be delivered. Olivier > > while i can see why we dont want to introduce new python2-only > package, i feel that just providing a py3k pkg while the module is > also py2 compatible is a disservice to our users: wether we like it or > not, python 2 is the de facto interpreter for python and not having a > module available will not just make everyone switch to py3k (i already > faced it a couple of times already, where i needed a module to extend > an already existing project, and it was not there) > > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? > > apps/scripts are fine being py3k by default, but the underlying > modules has to be provided by for py2 if compatible. > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > G+: https://plus.google.com/u/0/+SandroTosi > >
on keep providing python 2 packages
I got a feeling we are somehow discouraging the introduction of python2 package in unstable (it was also discussed at the BoF). while i can see why we dont want to introduce new python2-only package, i feel that just providing a py3k pkg while the module is also py2 compatible is a disservice to our users: wether we like it or not, python 2 is the de facto interpreter for python and not having a module available will not just make everyone switch to py3k (i already faced it a couple of times already, where i needed a module to extend an already existing project, and it was not there) does anyone else agrees with this view? should we clarify that, when available, python2 modules must be provided (along with their py3k)? apps/scripts are fine being py3k by default, but the underlying modules has to be provided by for py2 if compatible. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
