Re: Python package providing both modules and an app
On Jun 22, 2016 7:54 PM, "Barry Warsaw" wrote: > > On Jun 22, 2016, at 11:25 AM, Ben Finney wrote: > > >This seems to be more common now that command-line invocation is > >becoming even more discouraged. When the upstream documentation > >recommends ‘python3 -m foo.bar’ as the primary means of invoking the > >command line functionality, that really blurs the line between > >command-line application versus library. > > Indeed. It's true that -m invocation isn't as pretty as a /usr/bin script, > but it does have the advantage of unambiguously choosing the Python version > you want to run the script with. How important that is depends on the > application of course. > > >There is a compounding tendency to disparage ‘python3 ./foo/bar.py’, > >which is subject to weird hacks and incomplete workarounds like > >https://www.python.org/dev/peps/pep-0366/>. I wish this trend could > >be effectively reversed, because IMO this is a serious impediment to > >considering Python a good choice for command-line scripting. But this is > >all a digression, my apologies. > > Sorry, I don't quite understand the above. Do you mean that you would rather > use `python3 ./foo/bar.py` more often and `python3 -m foo.bar` less often? > > In any case, thanks Hugo for choosing Python 3 as the version to use for the > /usr/bin script. :) Speaking with my application developer hat on, the latter invocation ideally helps the user be more aware of what version of Python they're using. This is beneficial in a couple cases: - pip installing something: it's important for the user to know which version of Python they're using - running flake8 against a codebase. Flake8 relies on the version of Python's AST for certain things. If the user is writing code with async keywords but running Flake8 on Python 2.7, then they'll be in for a world of unpleasantness. By extension the same logic applies to any application that supports multiple versions of Python but depends on things like the stdlib AST module. It's certainly a hideous invocation, but it has it's benefits. Cheers, Ian
Re: Test suite in github but missing from pypi tarballs
On Thu, Apr 21, 2016 at 10:23 AM, Fred Drake wrote: > On Thu, Apr 21, 2016 at 10:54 AM, Tristan Seligmann > wrote: >> With my upstream developer hat on: source packages on PyPI are meant for end >> users to install via pip. They often include generated artifacts, and don't >> include things that aren't intended for installation via pip (tests being >> just one of these). > > Interesting. In many years of working with Python (since before > either PyPI or pip), I have a slightly different perspective. > > Source packages (whether on PyPI or not) with a setup.py (or whatever > comes next) are intended for both automated or developer consumption. > pip is just one possible tool; buildout is another, and others as > well. In the long history of both Python and its packaging this is absolutely true (all you need is an archive and a setup.py) but Python's packaging has evolved and improved for its users through setuptools, pip, and wheel (even though I'm sure there are many on this list who vehemently disagree). So tar files, for the *majority* of PyPI are there to help users with ancient, barely working, versions of pip, buildout, etc. >> For distribution packaging purposes, the GitHub tags are generally >> preferrable. GitHub makes archives of tagged releases available as tarballs, >> so this is generally a simple tweak to debian/watch. > > I'd generally be worried if the source package doesn't closely match a > tag in whatever VCS a project is using, but I don't think that's > essential, release processes being what they are. There's also a lot of data that could be in a VCS tag that is orthogonal to what needs to be in a package for a user or redistributor. For example, few if any people are going to want a file that configures the (potentially closed-source) continuous integration service(s) that the project uses and it's inconsequential to a redistributor if a .gitignore is in the archive too. Some of this will just needlessly inflate the package size. > This is really independent from the debate as to whether a test suite > should be included with the package, though. Agreed. It's just interesting.
Re: Joining the team
On Thu, Dec 31, 2015 at 11:21 AM, Scott Kitterman wrote: > On Thursday, December 31, 2015 08:31:31 AM Ian Cordasco wrote: >> Hi everyone, >> >> I would like to join the debian-python team. I have read the policy at >> >> https://python-modules.alioth.debian.org/python-modules-policy.html >> >> and accept it. >> >> My Alioth account is sigmavirus24-guest. >> >> I would like to join the team to help package and maintain >> python-betamax (ITP >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808880) with Daniele >> Tricoli. >> >> I don't maintain any other Debian packages and I'm not part of any >> other teams, but I'm eager to learn and help. >> >> Thanks! >> Ian > > Welcome to the team. Thank you!
Joining the team
Hi everyone, I would like to join the debian-python team. I have read the policy at https://python-modules.alioth.debian.org/python-modules-policy.html and accept it. My Alioth account is sigmavirus24-guest. I would like to join the team to help package and maintain python-betamax (ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808880) with Daniele Tricoli. I don't maintain any other Debian packages and I'm not part of any other teams, but I'm eager to learn and help. Thanks! Ian
Re: PyPI wheels (was Re: Python Policy)
On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote: > On Oct 21, 2015, at 08:47 PM, Brian May wrote: > >>in one case this is because upstream have only supplied a *.whl >>file on Pypi. > > I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads. I'm not sure why they should prohibit binary wheel-only uploads. A company may wish to publish a binary wheel of a tool and only that (a wheel for Windows, OS X, different supported linux distributions, etc.). If they do, that's their prerogative. I don't think there's anything that says Debian (or Ubuntu) would then have to package that. PyPI is not just there for downstream, it's there for users too (although the usability of PyPI is not exactly ideal).
Re: managing transitions
On Tue, Oct 6, 2015 at 1:11 PM, Barry Warsaw wrote: > On Oct 06, 2015, at 07:05 PM, Thomas Goirand wrote: > >>Interesting. It's the first time I hear about it, I thought it was just >>closed source. > > The instance at gitlab.com is the non-free Enterprise Edition (EE). EE has > features we probably don't care about ayway. The Community Edition (CE) is > MIT/Expat. > >>Does it have test capabilities as well, so that we could >>run tests on each new patch, like Gerrit does? Can we plug zuul and >>nodepool to it? > > I don't know about plugging in zuul and nodepool, but the CE does have CI > integration, which we use in the GNU Mailman project, and seems to work > great. It definitely can integrate with its own CI (which I believe is also licensed similarly to GitLab CE) as well as Jenkins. Currently the Flake8 project is hosted and developed on GitLab and uses integration with vanilla Jenkins.
Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)
On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley wrote: > On 2015-10-06 09:28:56 +0200 (+0200), Thomas Goirand wrote: >> Master != kilo. It still means that I have to do all of the backport >> work by myself. > [...] >> I know that it's the common assumption that, as the package maintainer >> in Debian, I should volunteer to fix any issue in the 6+ million lines >> of code in OpenStack ! :) >> >> I do try to fix things when I can. But unfortunately, this doesn't scale >> well enough... In this particular case, it was really too much work. > > That is the trade-off you make by choosing to maintain as many > packages as you do. You can obviously either spend time contributing > stable backports upstream or time packaging software. Just accept > that, as with Debian itself, "stable" means OpenStack upstream makes > the bare minimum alterations necessary. This includes, in some > cases, continuing to test the software in those branches with > dependencies which were contemporary to the corresponding releases > rather than chasing ever changing behavior in them. Sometimes it is > done for expediency due to lack of interested volunteer effort, and > sometimes out of necessity because dependencies may simply conflict > in unresolvable ways. And to be fair, this has been discussed many times on the mailing list with you Thomas. The ratio of cores to stable maintenance cores is probably something upwards of 5:1. Most of the latter group are also members of the former group which means they have double the responsibility (if not more, because stable maintenance is a lot more involved than a place on the regular core reviewer team). The reality is that stable packages relying on versions that were contemporary at the time of their release is very very reasonable (and that's how, e.g., stable linux distros work). After all "stable" is just the name for "broken in ways we know about", otherwise one would call it "perfect" for being forever in a working state under all unexpected conditions (which no piece of software really is).
Re: I've been removed from the Python team
On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue wrote: > On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: >> [Thomas Goirand, 2015-09-30] >> > Piotr decided to remove me from the Python team. >> >> DPMT and PAPT to be precise, yes >> >> > is an over reaction and that it should be reverted. >> >> I talked with you many times in private about your involvement in the >> teams over last ~3 years and since I kind of forced other admins into >> accepting you, I also take all the blame for removing you. >> As I said in the private mail earlier today, if you still want to work >> with me, I'm happy to review / sponsor your commits in DPMT or help with >> any problems you might have with tools I wrote. > > Dear Piotr, > > Even if I'm not in the team and thus I do not decide of anything, I > wonder if that's an appropriate answer, regarding the initial trouble. > > We are currently talking about preventing Thomas to maintain his > packages that has DPMT as maintainer, because he uploaded something in > experimental, which is neither a release, nor a distro of any kind. > > Considering the potential trouble it'll lead to (as for an example it'll > probably send my attempt to package mailman3 to nowhere), and the > potential bad consequences for python team (some packages no longer > maintained, etc), does it worth it? > > -- > PEB Pierre, I'm new to the team, mailing list, etc. (honestly, I never had a chance to formally introduce myself to everyone) but it looks as if Piotr has had several instances in the past where he's had to discipline Thomas. I doubt this is an action that Piotr took lightly. Further, I doubt those packages will suddenly go unmaintained. Please continue working on mailman3, it will benefit the community far more than the outcome of this apparent disciplinary action. Cheers, Ian
Re: Removing some python3-* packages
On Jul 9, 2015 5:25 AM, "Robert Collins" wrote: > > On 3 July 2015 at 08:29, Scott Kitterman wrote: > > > I think dropping these duplicates is the only thing that makes sense. For > > reference, I dropped python3-ipaddr once python3.2 was gone (because 3.3 has > > ipaddress, which does the same thing). > > Where its a dupe sure. > > unittest2, traceback2, linecache2, mock are not duplicates of the > functionality in 3.4 - they are backports of things in 3.5 (to all > pythons). And they will shortly have more than 3.5 itself has in it, > as they are rolling backports: what lands in 3.6 will go into them. So > I don't think removing them makes sense. > > I don't have a view on other packages. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/CAJ3HoZ0a9rSSAc-zv+7qhP+0n-wMGQ=hrm__togtuesopuk...@mail.gmail.com > Further, should API compatibility also be considered? If I remember correctly ipaddress in the stdlib and ipaddr have similar but not exactly identical APIs
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins wrote: > On 3 July 2015 at 11:44, Ian Cordasco wrote: >> On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney >> wrote: >>> Barry Warsaw writes: >>> >>>> […] there's actually no reason to have a Python 3 version of enum in >>>> any version >= Python 3.4. […] >>> >>> Ian Cordasco writes: >>> >>>> Probably a silly question, but are other libraries like unittest2 also >>>> being packaged for python3? Another library is mock. That was included >>>> in the stdlib in 3.3. >>> >>> One consideration is: What code is written to be Python 2 and Python 3 >>> compatible from the same code base, which achieves this by importing a >>> module which is backported to Python 2? >>> >>> In some of my code I'm doing ‘import unit2’ to have features from that >>> library available in Python 2 code. >>> >>> Since those features are all in Python 3's standard library, the case >>> could be made that ‘python3-unit2’ is pointless; but against that is the >>> fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work >>> the same on both runtime versions. >>> >>> So I'd argue that ‘python3-mock’ and the like do have a place in Debian: >>> they make it easier to follow the recommended strategy of having a code >>> base run unchanged on Python2 and Python 3. >> >> Just to be clear, trying to use mock on 3.4 is thoroughly broken. If >> you can install python3-mock right now and use it in 3.4, then y'all >> must be carrying patches to make it work. The last 3.x version that >> mock works on is 3.3. >> >> That clearly doesn't have a place on a debian with python 3.5 as the >> version of python 3 included, unless you're planning on supporting >> packages for python 3.3 as well that will generate a numerous amount >> of bugs for you. > > See my prior mail. I will be backporting all the changes in mock from > the stdlib to the mock standalone lib in the near future. > > I have upload acls from Michael Foord for PyPI and I'm not afraid to > use them to fix it up - if you wanted to prep a narrow patch to fix > 3.4 then please do so here - https://github.com/testing-cabal/mock Will do in the next couple weeks. I had chatted with Michael about it on Twitter and he expressed no interest in supporting it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu1cv9BxZWb3TAte_WXe2QEkabZe8ZOd32BAL3u8=4g...@mail.gmail.com
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney wrote: > Barry Warsaw writes: > >> […] there's actually no reason to have a Python 3 version of enum in >> any version >= Python 3.4. […] > > Ian Cordasco writes: > >> Probably a silly question, but are other libraries like unittest2 also >> being packaged for python3? Another library is mock. That was included >> in the stdlib in 3.3. > > One consideration is: What code is written to be Python 2 and Python 3 > compatible from the same code base, which achieves this by importing a > module which is backported to Python 2? > > In some of my code I'm doing ‘import unit2’ to have features from that > library available in Python 2 code. > > Since those features are all in Python 3's standard library, the case > could be made that ‘python3-unit2’ is pointless; but against that is the > fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work > the same on both runtime versions. > > So I'd argue that ‘python3-mock’ and the like do have a place in Debian: > they make it easier to follow the recommended strategy of having a code > base run unchanged on Python2 and Python 3. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/can-kwu1os1+grzrbcx41jsbs2uqgwxukmw2usgmgfo4safd...@mail.gmail.com
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw wrote: > As part of the 3.5 test rebuild I noticed an incompatibility with > python3-enum, which I reported upstream. The response was: there's actually > no reason to have a Python 3 version of enum in any version >= Python 3.4. > Since that's all we have now, maybe it makes more sense to just remove the > python3-enum package from Debian. > > There may be similar packages which are fairly straight backports of Python 3 > packages. For those that are no longer necessary, what do you think about > removing the python3-* version of the binary package? > > It seems like a bit of a regression given that we want Python 3 versions of > our libraries, but in cases like this it probably makes sense. > > Thoughts? > -Barry Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. Is that being packaged for python3 on Debian as well? I know it's nice to have the libraries available on both, but mock for example stopped working on python3.4 since it's solely maintained in the stdlib now. It doesn't make sense to package that for both. (Keep in mind, I'm just an observer and I haven't checked if those examples are already packaged for Py3) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu0t=SKW=9gH6HYGLZZNW76rvchnZVzp8Hm6C1T=ux4...@mail.gmail.com
Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3
On Fri, May 22, 2015 at 10:12 AM, Tristan Seligmann wrote: > On 22 May 2015 at 16:06, Tristan Seligmann wrote: >> Or are you saying that the ipaddress backport is not compatible with >> python3 stdlib's ipaddress? (This would be a very unfortunate state of >> affairs, but impossible to imagine) > > This should have been "*not* impossible", of course. Based purely on the fact that the current version of ipaddr is undocumented, I would strongly be against any patch to packaged software that causes a dependency on it for the sole purpose of Debian's packaging of that software. You're asking the maintainers of those packages to maintain patches for things that are undocumented. In my opinion, Scott, if your'e so adamant about not packaging ipaddress for Python 2, you should work with ipaddr to fix things so maintainers can reliably maintain the software. Until that is fixed, I think Tristan's packaging should move forward so Debian doesn't fall too far behind pip. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu2fGHqo7=+qj4uox2u4h9nfxzolsnwfxgpgvsf60sf...@mail.gmail.com
Re: requests 2.7.0 in Debian experimental
On Tue, May 5, 2015 at 10:01 AM, Daniele Tricoli wrote: > Hello, > > I have uploaded version 2.7.0 of requests in experimental because it breaks > backwards compatibility. > > I already found that httpie needs to be update to 0.9.2[¹], but I'll start > checking all requests dependants in the following days. > If your package has requests as dependency, and you want help me (:D), > please > test it with the new version and make sure all it's fine. > > My plan is to systematically check dependants before ask from the release > team > a transition slot for requests (this should be the proper way to handle > this > issue IIUC). > > Kind regards, > > [¹] > > https://github.com/jakubroztocil/httpie/blob/master/CHANGELOG.rst#092-2015-02-24 > > -- > Daniele Tricoli 'Eriol' > https://mornie.org Thanks for being so awesome Daniele! To elaborate on the problem with httpie: We are trying to start cleaning up a lot of technical debt. There were constants defined in requests.compat and httpie was relying on some of those instead of determining them for itself/using a library like six. I checked a bunch of consumers before removing those constants, but I missed httpie. Needless to say, we haven't add those back since httpie released a fix very quickly. To make it easier for everyone else, if you want to grep through the packages you maintain for any of the symbols removed here: https://github.com/kennethreitz/requests/commit/f37fe551bbbf6ac8d07c35c64888b4ab289c967d it should be sufficient. Cheers, Ian
Re: Python 2 d-d-a proposal
On Wed, Apr 15, 2015 at 3:27 PM, Paul Tagliamonte wrote: > Heyya d-p, > > I'd like to send an email to d-d-a asking that project to consider no > longer creating new Debian tools in Python 2. > > I'd like this to have the endorsement of the team, so, does anyone object > to > me asking people to not write new tools in Python 2 only (prefer > alternative > deps or porting), and only use Python 2 in very special curcumstances or > for legacy codebases (perhaps a pitch to move to Python 3), along with a > note that we plan to deprecate Python 2 when upstream support is gone > (2020), which puts us on track for two cycles (Buster) > > > I'll make note of a team which should exist to help with such porting, > (I'm up to help with this) that was one of the items that came out of > the PyCon chit-chat. I got the sense from the room that this would be > OK, but just checking if anyone here has a substantive objection. > > If not, I'll send that out later on today/tomorow. > > > Thanks! > Paul > > -- > .''`. Paul Tagliamonte | Proud Debian Developer > : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 > `. `'` http://people.debian.org/~paultag > `- http://people.debian.org/~paultag/conduct-statement.txt > Hey everyone! I realize I haven't made a formal introduction of myself to this list (I'll do that some other time), but I have a fairly significant amount of experience adding Python 3 compatibility to tools while retaining Python 2 compatibility (I recently just helped SQLObject release 3.0.0a1 which is the first version to support Python 3.4). We might want to move to making the tools compatible first and then drop support for Python 3. Also, I'm very much up for helping with this. Cheers, Ian
