Re: Bug#834768: RFS: codicefiscale/0.9-1
On Sat, Aug 20, 2016 at 10:05 PM, Elena ``of Valhalla'' wrote: > Thanks. I currently check packages with lintian (--pedantic) and > piuparts, and I sort-of-know-but-still-don't-use check-all-the-things: If it helps convince you to use it, installing without recommends will lead to knowing which tools to install for the specific package you are checking. Also, patches welcome for the Python TODO list :) https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README#n33 > is there something else I should/can add to the list? I guess you are already running it via piuparts, but run adequate on the installed packages. Adding some DEP-8 tests might be a good idea: http://dep.debian.net/deps/dep8/ More stuff will get run when it reaches Debian: https://wiki.debian.org/qa.debian.org -- bye, pabs https://wiki.debian.org/PaulWise
Re: on keep providing python 2 packages
On Aug 20, 2016, at 1:19 PM, Sandro Tosi wrote:
> i'd like to hear the opinion of the dpmt admins and python maintainers
> on the OP matter: public module py2 mandatory support, or -in a
> boarder shape- to provide debian packages for all the versions of
> python an upstream public module supports in its code.
I’m just a user, not a maintainer or developer, but IMHO it makes sense to
provide debian packages for all versions, and only those versions, in the
intersection of the two sets {supported by upstream} and {supported by debian}.
Anything outside of that intersection either adds work for the debian
maintainers or would be useless to debian users.
Enjoy!
Rick
Re: on keep providing python 2 packages
[Sandro Tosi, 2016-08-20] > i'd like to hear the opinion of the dpmt admins and python maintainers > on the OP matter: public module py2 mandatory support, or -in a > boarder shape- to provide debian packages for all the versions of > python an upstream public module supports in its code. IMO: * all Python applications that support it, should use 3.X only *now* (and do not bother with things like alternatives or "-3" suffixes / "python3-" prefixes - at least for new packages; I'd even slowly start removing alternatives, if it doesn't affect users), * libraries in Stretch should support 2.X (i.e. add python-foo binary packages) if that doesn't require too much additional work (py2dsp still creates them). I'm OK with shipping 3.X only packages in NEW packages, though. I'd not encourage people to do so but also not forbid it, * we shouldn't accept 2.X only packages in Buster (Stretch+1, released ~2019) unless they're a dependency of other packages, and start shipping 3.X only packages where it makes sense (and I hope that decision will be mostly made by upstreams by simply dropping 2.X support). We can drop some 2.X packages (problematic to maintain? better alternatives available? low popcon?), but do not do a mass removal yet, * for Bullseye (Stretch+2, released ~2021) we should start dropping 2.X packages, and maybe even remove 2.X interpreter, * Bullseye + 1 (~2023) is the one without 2.X interpreter and python-foo packages for sure (and without /usr/bin/python symlink or at least without Debian packages mentioning it, there should be a rule to not speak about /usr/bin/python symlink! ;) Note that Python upstream will stop supporting 2.X in ~2020 so about one year (and a half?) after releasing Buster. -- 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 signature.asc Description: PGP signature
Re: on keep providing python 2 packages
On Sat, Aug 20, 2016 at 8:05 PM, Mattia Rizzolo wrote: > > On Sat, Aug 20, 2016 at 05:42:24PM +0100, Sandro Tosi wrote: > > anyway, why wouldnt you want to provide a python2 package if the code > > supports it? if you got a py3k package working, it's usually > > straightforward to have a py pkg. Doing that i've found several issues > > with upsteam projects that were fixed, thus increasing the general > > quality of their code and our distributionsuggestions > > my opinion: > > it just makes no sense to discuss this now: > + it's less than 6 months from the freeze so, should we stop development/evolution/improvement? > + I doubt that there will be that many "affected packages" right now, >much less that many "buggy" (by your proposal) indroced in the next >few months; I don't recall seeing any example in any email. dont draw conclusions without having crunched the numbers (i havent myself), but there were already cases where the python2 support was missing while it was available upstraem: http://bugs.debian.org/802582 let's fix this before it becomes widespread: better fix 3 (say) packages than 100 i think > + I very much hope we'll manage to get buster out without python2, in >that case thinking about shipping py2 modules now when we're going to >drop them next year would be a plain waste of time. it's way to early to say how the evolution will be, but given how things are now, i very much hope that will NOT be the case, and we'll be able to ship py2 interpreter and modules in buster. anyway, this is way offtopic. > I'm curious: what triggered this email of yours? http://bugs.debian.org/834777 i'd like to hear the opinion of the dpmt admins and python maintainers on the OP matter: public module py2 mandatory support, or -in a boarder shape- to provide debian packages for all the versions of python an upstream public module supports in its code. > > -- > 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 `- -- 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
On Sat, Aug 20, 2016 at 05:42:24PM +0100, Sandro Tosi wrote: > anyway, why wouldnt you want to provide a python2 package if the code > supports it? if you got a py3k package working, it's usually > straightforward to have a py pkg. Doing that i've found several issues > with upsteam projects that were fixed, thus increasing the general > quality of their code and our distribution my opinion: it just makes no sense to discuss this now: + it's less than 6 months from the freeze + I doubt that there will be that many "affected packages" right now, much less that many "buggy" (by your proposal) indroced in the next few months; I don't recall seeing any example in any email. + I very much hope we'll manage to get buster out without python2, in that case thinking about shipping py2 modules now when we're going to drop them next year would be a plain waste of time. I'm curious: what triggered this email of yours? -- 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: on keep providing python 2 packages
On Fri, Aug 19, 2016 at 6:26 PM, Dmitry Shachnev wrote: > 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). but you are not aware of all the potential users of the py2 version, they are none now because there is not such version available for them (as Elena mentioned out in her reply) > >> 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? that text was not meant to be a patch to the policy (yet), but the idea is to be mandatory to support every version upstream supports, so the should is just too weak: you can if you want, but you are not forced to. the must expresses that's mandatory anyway, why wouldnt you want to provide a python2 package if the code supports it? if you got a py3k package working, it's usually straightforward to have a py pkg. Doing that i've found several issues with upsteam projects that were fixed, thus increasing the general quality of their code and our distribution -- 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: Bug#834768: RFS: codicefiscale/0.9-1
On 2017-08-19 at 20:54:34 +, Mattia Rizzolo wrote: > 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 -.-' lol :) > > 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 :) Well, the scope of the project is quite limited, and it its feature set is basically complete or nearly so, so the lack of commit activity doesn't worry me. Around the time when I opened that issue I also proposed a (small) pull request to add python3 support and that one was accepted in a very short time, so the project didn't look abandoned. https://github.com/ema/pycodicefiscale/pull/5 > > > * 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) > [...] > This is not going to do what you expect, check both the produced > binaries ;) yeah, that did exactly half of what I expected :) should be fixed now (also in git) > (`debc` right after having built the package is handy for that, I run > it in a pbuilder hook for example) Thanks. I currently check packages with lintian (--pedantic) and piuparts, and I sort-of-know-but-still-don't-use check-all-the-things: is there something else I should/can add to the list? -- Elena ``of Valhalla'' signature.asc Description: PGP signature
Re: on keep providing python 2 packages
On 2016-08-19 at 13:42:52 +0300, Dmitry Shachnev 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). > > What’s the point of shipping the Python 2 version of that module then? Speaking with the assumption that (as mentioned elsewhere in the thread) the module is written in a way as to be potentially useful for other users than the app. As somebody who writes (and keeps running, see debops_) python code for internal use targetting debian stable, I find that packaged modules are extremely useful even if they aren't used as a dependency for some app inside debian, and using them a much saner alternative than getting dependencies with pip inside a virtualenv. .. _debops: http://www.enricozini.org/blog/2014/debian/debops/ In this case, there is no real way to know whether people are using python2 or python3 (except for hints from popcon, that aren't available however is the python2 version doesn't exist in debian). > In my opinion, we should neither encourage nor discourage shipping the > Python 2 version, and let the maintainer make the decision. I can imagine that there may be cases where adding a py2 version could mean significant more work for the maintainer, and I can understand people not being happy having to do that work for a legacy language that will be removed in a few releases, but I don't thing it's reason enough not to encourage shipping py2 versions in the vast majority of cases where the effort required is low. -- Elena ``of Valhalla''
