so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
no I mean, really, read http://pkg-perl.alioth.debian.org/git.html * they have a tool that automatically creates (and push) a new package from CPAN, and sets everything up with the team standards; the same should happen for python and pypi. and there is tool (dpt) to manage the other common packaging tasks * they do not force as default the use of an unnecessarily convoluted "patch regime" - just stick to the path of least resistance, quilt unapplied-patches is perfectly usable with git and is a method every one can use (and should know anyway), without tying the patch to the SCM tool we are using * you can choose more complex ways to do things, but not as the default (because -you know- you want us to buy the story "if we migrate to git, hordes of contributors will come", then keep the process as simple as possible, and be flexible to more skilled maintainers if they want to) * they have a way to download all the packages and do mass-commit on them they manage more than 3k packages, their approach works in practice and scales, do we really need to reinvent the wheel here? (as I'm quite sure at debconf there will be discussion about it, this my input on the matter) -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxxcakhj9wdb_q1cnkdi4q1gex7sd4ir+o2wjn6vhub...@mail.gmail.com
Bug #751908, tox, and bin-only Python packages
Back in June 2014, I filed bug #751908, which Piotr closed as wontfix. This is really related to an open question in Python packaging concerning a standard naming scheme for packages which provide Python applications (e.g. /usr/bin scripts) whether or not they also provide importable libraries, although it's trickier when they don't (e.g. tox). AFAICT, Debian Python Policy is silent on this. The example that sparked issue #751908 was tox, which when I initially packaged it, I called the binary package python-tox. I did this because, while the package does not provide any publicly importable modules, I felt it was presumptuous to claim a rather generic name like 'tox' as the binary package. As it turns out, almost 3 years later there are no other claims on binary package name 'tox' in the archive, so my concern might have been unnecessary. The reason I opened the bug was because of dh_python3's behavior that the normal set of renames (e.g. usr/lib/python3.X/dist-packages to usr/lib/python3/dist-packages) isn't done for binary packages named with the python- prefix. I follow and largely agree with Piotr's reasoning for closing bug wontfix, but that still doesn't help. ;) This is biting me today as I try to fix the tox source package so that it will build in a world with two supported Python 3 versions, as is the case in Ubuntu 15.10 currently. The hack in d/rules I had been using breaks with multiple versions of Python 3. I can fix the hack, or I can rename the binary package to 'tox'. I'm strongly inclined to the latter, with either a dummy transitional package or a provides/replace/conflicts transition. I'm happy to hear your thoughts on that, but let's talk about the larger issue. Should there be a naming convention for Python packages which only provide an executable? Clearly they can't be called 'python-foo' or 'python3-foo'. We're reserving those names for binary packages that provide importable libraries of the appropriate language version. Ideally you could just claim 'foo' but there may be problems with that. 'foo' might collide with some other existing package name. In other cases, maintainers might consider it presumptuous and not very friendly to claim a generic name. What should we recommend? Do we need to recommend anything, or do we just let the maintainer decide? At the very least, DPP must proscribe using python-foo or python3-foo. Cheers, -Barry pgpVNd4C_Bh56.pgp Description: OpenPGP digital signature
Re: Bug #751908, tox, and bin-only Python packages
[Barry Warsaw, 2015-08-06] > Should there be a naming convention for Python packages which only provide an > executable? everything that doesn't match python[\d.]*- is fine IMHO. If "tox" is too generic, use tox-python -- 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 -- 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/20150806150835.gb2...@sar0.p1otr.com
Re: Bug #751908, tox, and bin-only Python packages
On 06/08/15 15:50, Barry Warsaw wrote: > The example that sparked issue #751908 was tox, which when I initially > packaged it, I called the binary package python-tox. I did this because, > while the package does not provide any publicly importable modules, I felt it > was presumptuous to claim a rather generic name like 'tox' as the binary > package. If it's pollution in the flat namespace of packages, then it's pollution in the flat namespace of "what's in $PATH". If it isn't, it isn't. Pick one? :-) > Should there be a naming convention for Python packages which only provide an > executable? Policy has this to say on the subject of a different flat global namespace: "When scripts are installed into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it." Does similar reasoning make sense for package names - the user of the package is looking for the functionality of the package, not the implementation language? If disambiguation is needed due to a naming conflict, a descriptive prefix/suffix might make more sense: "tox-tester" or "tox-python-tester" would be in the same spirit as chromium-browser (now chromium) vs. the game Chromium B.S.U. (now chromium-bsu), and nodejs vs. ax25-node fighting over "node". (Note the subtle distinction that nodejs is *for use with* JavaScript, not *written in* JavaScript.) S -- 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/55c37b4a.90...@debian.org
Re: Bug #751908, tox, and bin-only Python packages
On Thu, Aug 6, 2015 at 17:08:35 +0200, Piotr Ożarowski wrote: > [Barry Warsaw, 2015-08-06] > > Should there be a naming convention for Python packages which only provide > > an > > executable? > > everything that doesn't match python[\d.]*- is fine IMHO. > > If "tox" is too generic, use tox-python If "tox" is too generic, then that would also apply to "/usr/bin/tox" IMO. (Collisions over command names are even worse than collision over package names, since they have way more impact on users.) Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20150806152150.gk5...@sh76.dev.logilab.fr
Re: Bug #751908, tox, and bin-only Python packages
On Aug 06, 2015, at 04:20 PM, Simon McVittie wrote: >Policy has this to say on the subject of a different flat global namespace: > >"When scripts are installed into a directory in the system PATH, the >script name should not include an extension such as .sh or .pl that >denotes the scripting language currently used to implement it." > >Does similar reasoning make sense for package names - the user of the >package is looking for the functionality of the package, not the >implementation language? It does make sense to me that the package name containing the executable should reflect the executable's name. Thus in this case, the binary package name 'tox' makes the most sense. >If disambiguation is needed due to a naming conflict, a descriptive >prefix/suffix might make more sense: "tox-tester" or "tox-python-tester" >would be in the same spirit as chromium-browser (now chromium) vs. the >game Chromium B.S.U. (now chromium-bsu), and nodejs vs. ax25-node >fighting over "node". (Note the subtle distinction that nodejs is *for >use with* JavaScript, not *written in* JavaScript.) See my previous follow up for proposed DPP language here. Feedback welcome! Cheers, -Barry -- 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/20150806150832.125da...@limelight.wooz.org
Re: Bug #751908, tox, and bin-only Python packages
On Aug 06, 2015, at 05:08 PM, Piotr Ożarowski wrote: >everything that doesn't match python[\d.]*- is fine IMHO. Here's some language for DPP: === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2015-02-27 23:09:27 + +++ debian/python-policy.sgml 2015-08-06 19:04:43 + @@ -728,6 +728,25 @@ package itself. + + +Package Names for Programs + + Binary packages that provide executable programs should be named + differently than module packages. + Specifically, such binary packages should not start with + either python- or python3- as + this is not supported by the Python helper scripts for this purpose. + Generally, if a single executable is provided, name the package that + contains it after the executable's name. If that is too generic, or + clashes with existing package names, or the package contains + multiple executables, use something + like foo-cli, + foo-bin, + or even foo-python. + + + >If "tox" is too generic, use tox-python I'm going to name it 'tox' and create a virtual transitional package python-tox with the appropriate replaces/breaks. Cheers, -Barry -- 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/20150806150656.0996b...@limelight.wooz.org
Re: Searching for sponsor and critique
Hey, > I believe that we are still using SVN but maybe the switch to git will > be done during the next Debconf. > > Personnaly, I don't really care if a package is team-maintained or > not. It is better if it is and it will allow you to find another sponsor > in case your regular sponsor is unresponsive. So, please apply to DPMT > for python-prompt-toolkit. Do you already have an Alioth login? If not, > please create one. I found a lot of automatic SVN imports on the git side of Alioth so I assumed the whole project is preparing a move so I went with what I knew best and used gbp and git-pbuilder. I have an Alioth login and I use it for my other packages. But I do need to apply to DPMT. >> [6] https://git.ring0.de/debian/python-prompt-toolkit > > - d/changelog: remove the "source package automatically created by >stdeb" > - d/control: use python-prompt-toolkit as a source package name, as it >would avoid any future collision (and it is also the name for the >GitHub repository) > - d/control: add the appropriate Vcs-* (which will be updated later, >just to not forget them) > - d/control: short description should not start with a capital > - d/rules: remove the comment about automatic generation I fixed those. I didn't add Vcs yet as I hadn't uploaded it to Alioth. I just set them to my git hosting for now and will change them when the upload is done. Same with the Maintainer field. The clone URL was at the top hidden behind the cloud download icon. But as I said I also added them to the control file now if you want rtto do test builds. I'll get back to you after the DPMT application. Lennart -- 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/55c3c047.3080...@lennartweller.de
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote: >no I mean, really, read http://pkg-perl.alioth.debian.org/git.html Thanks for the link Sandro. Reading this, I think it's on par with our https://wiki.debian.org/Python/GitPackaging by which I mean it's prescriptive of how to do common tasks in a team collaborative way, but neither document really provides much rationale on *why* those particular recipes were chosen. >* they have a tool that automatically creates (and push) a new package >from CPAN, and sets everything up with the team standards; the same >should happen for python and pypi. and there is tool (dpt) to manage >the other common packaging tasks Certainly we could do the same, but TBH, with a working d/watch file, I've never much found it necessary. What I'd actually like is for `git-dpm import-new-upstream` to take no-args and then do a uscan to get the orig.tar in that case. That seems like it would be a fairly simple patch. Afaict, dpt is a tool sitting in a special git repo, not even in the archive. So it's a non-standard thing that members of the Perl team will have to install and learn and while you could claim that git-dpm is also such a tool, it's 1) in the archive; 2) not at all specialized toward Python. In any case, it's still Another Tool To Learn. >* they do not force as default the use of an unnecessarily convoluted >"patch regime" - just stick to the path of least resistance, quilt >unapplied-patches is perfectly usable with git and is a method every >one can use (and should know anyway), without tying the patch to the >SCM tool we are using But, is that a good thing? quilt itself is a PITA to use IMHO, and I find it very nice that with git-dpm, once you're switched to the patches branch, all you have to know is git commands. You modify the upstream source in place, and git commit to your heart's content. If you must, `git rebase -i` and do other git-y things without having to worry about quilt refreshing, making sure your patches are created at the correct patch-level, dealing with rejections, push, pop, quilt apply -f, and other such crazy stuff when the patches don't apply, etc. If you say that patch stack management is a PITA either way, I won't argue. :) But I do think it's generally easier when staying in git as long as possible, and dealing with other-tool peculiarities only at the boundaries. >* you can choose more complex ways to do things, but not as the default >(because -you know- you want us to buy the story "if we migrate to git, >hordes of contributors will come", then keep the process as simple as >possible, and be flexible to more skilled maintainers if they want to) That's not necessarily why *I* want to switch to git. I think it's more or less a myth that the migration to git suddenly increases the volume or quality of contributions. I want us to switch to git because git is just a better vcs than svn, for reasons I don't need to explain to anybody. Switching to git will make the *current* DPMT members lives easier, and if it reduces friction so more people will come to help us, bonus! >* they have a way to download all the packages and do mass-commit on them Which isn't impossible for us either, IIUC. I think mr would work for us after switching to git-dpm too, though I have not used it much and very rarely have ever wanted to do a mass commit (updated d/watch to use the redirector was the first time I thought, hmm, I'd love to mass commit that change). >they manage more than 3k packages, their approach works in practice >and scales, do we really need to reinvent the wheel here? I don't think we're reinventing the wheel! We're using just a few common tools and a pile of policy. In fact, we'll be using *fewer* tools that the Perl team (i.e. just git and git-dpm). No need for a special additional dpt tool, no need for quilt, and not preventing the use of conveniences like mr. I even think we're going to have less complex recipes and policies than the Perl team. >(as I'm quite sure at debconf there will be discussion about it, this >my input on the matter) Thanks for that! I won't be at Debconf this year, and if team members are there and the conversion is discussed, I hope summaries will be posted. We had some very thorough discussions at last year's Debconf, followed by lengthy discussions on the mailing list (and even some at Pycon), and through much hard work by folks like Stefano, now we're very close to flag day. I won't say that decisions are set in stone - I don't even have any authority to say that. IMHO, consensus, and those-who-do-the-work, rules. But I do hope we don't go back to square one. I think we're fairly well convinced that if git-dpm turns out to not be the right tool, we'll still have converted to git, and we can implement some other better workflow later. I still like git-dpm a lot, but we're not closing any future doors. (One interesting thing I've learned since last year, reading recent debian-devel th
Bug#794829: ITP: python-django-cors-headers -- Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-cors-headers Version : 1.1.0 Upstream Author : Otto Yiu * URL : https://github.com/ottoyiu/django-cors-headers/ * License : MIT Programming Lang: Python2 and Python3 Description : Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS) Pypi link: https://pypi.python.org/pypi/django-cors-headers Will be DPMT maintained. Required for another package I am creating. I think this is likely to be useful for other people besides myself. -- 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/20150807011318.15108.81449.report...@prune.in.vpac.org
