Re: wheel support for Debian?
If I provide a script that generates .whl file out of Debian binary package, would that make more sense than these -wheels packages? python3.X-venv could simply depend on required packages and run this script (with a list of required dependencies) when someone creates new venv. You can also pre-generate them in python3.X-venv's postinst but then a dpkg trigger is needed to regenerate them when one of dependencies is upgraded. -- 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/20140516084808.gh4...@sts0.p1otr.com
Re: RFS: confiture/2.0-1
On Tue, May 13, 2014 at 11:11 AM, Antoine Millet wrote:
> On Mon, 2014-05-12 at 22:16 -0700, Vincent Cheng wrote:
>> Hi Antoine,
>
> Hi Vincent,
>
>> I've cc-ed you in case you aren't subscribed to the list. Let me know
>> if you are so I can drop it.
>
> I already subscribed to the list, so you can drop it.
>
>> (it's pretty much the textbook example of pybuild/dh-python usage
>> although if you intend on maintaining it within the DPMT
>> (Debian Python Modules Team), please add Vcs-{Browser,Svn} links in
>> debian/control. You'll have to join the DPMT/PAPT on Alioth first [1]
>> first, however.
>
> I requested to join on Alioth, but an admin answered me to post here.
You'll have to be approved for membership into the DPMT/PAPT before
you'll get commit access to our svn packaging repos. If you've gotten
no further response, I suggest pinging the team admins on IRC (I think
Piotr is one of the admins?).
>> My one concern at this point is that I'm not sure how your library
>> differs from the various other packages that are already in the Debian
>> archive (e.g. "aptitude search parse"); I wouldn't be surprised if
>> there's some degree of overlap. I mean no offense by this, but I'm
>> somewhat reluctant to sponsor small "vanity" packages into Debian
>> because more often than not, they end up just bitrotting in the
>> archive once the author loses interest in it (or Debian, for that
>> matter), especially if nobody else actually uses the package / there's
>> no real user demand for it.
>
> I understand your concern, and I know that all I can say will be tainted
> by the fact that I'm also the author of this library.
>
> I started this project because I was not able to find anything like that
> in the Python ecosystem. The most similar project is ConfigObj, but the
> syntax of parsed files is significantly different and the way to validate
> too.
>
> I also maintains a Debian package for this library on my own repository
> since the beginning of the project (2 years ago) and imho, doing this
> work for Debian is probably more productive than doing it in my little
> corner.
>
> Finally, the library is not only used by me. I got some emails from users
> about bugs and suggestions, I also got issues and PR on Github, and the
> library has beeny packaged on some distro by other people (Archlinux[1]
> and Frugalware[2]).
In case nobody on this list is interested in your package, perhaps
you'd like to consider asking for sponsorship on other Debian
channels, e.g. debian-ment...@lists.debian.org, the
sponsorship-requests pseudo-package/bug tracker, or #debian-mentors on
OFTC?
>> However, we do have plenty of packages and teams in Debian that could
>> use an extra set of helping hands, and you are definitely more than
>> welcome to join the team and assist with team-maintained packages. I'm
>> certain that there are lots of packages in the DPMT/PAPT that could
>> use some extra love, especially those with RC bugs and/or inactive
>> uploaders; you can see [2][3] for a full list of packages we maintain,
>> some of which may interest you.
>
> I would be glad to help. Is updating some package to the latest upstream
> version a good way to start?
Sure, assuming it's team-maintained and nobody else is already working
on it. Bug fixing/triaging is also another great way to start
contributing. :)
Regards,
Vincent
--
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/caczd_tcwxfukbj4j5dg+1pqdfnjeypndo_eexkgya_w+wdh...@mail.gmail.com
Re: wheel support for Debian?
Hi Piotr, On May 16, 2014, at 10:48 AM, Piotr Ożarowski wrote: >If I provide a script that generates .whl file out of Debian binary >package, would that make more sense than these -wheels packages? > >python3.X-venv could simply depend on required packages and run this >script (with a list of required dependencies) when someone creates new >venv. You can also pre-generate them in python3.X-venv's postinst but >then a dpkg trigger is needed to regenerate them when one of >dependencies is upgraded. Since you've mentioned this several times, I wonder if you can explain why you prefer it over the build-wheels-at-package-build-time approach? A few things I worry about: since you won't be building the wheel from upstream (but quilt-patched) source tree, it's possible you'll have incomplete information and won't be able to build a wheel in the necessary format. You can't use bdist_wheel because you won't have a setup.py handy. You won't have a dist-info directory handy (I think - and not sure if that matters). Because you won't be running from a setup.py, you won't know for sure what needs to go into the wheel, and you might have to track down files from several locations on the file system. It *might* all work, but if there are corner cases that cause your script to build incompatible wheels, it'll be tougher to track down and fix the problems. If you build the dependent wheels when someone creates a venv, it'll take longer, although if it's noticeable you could cache the results, except that's more machinery that could have bugs (e.g. evicting the cache when packages get updated). postinst and dpkg triggers are more "magical" and so more difficult for others to understand and contribute to, although good documentation can mitigate that. It also seems like more moving parts for something that is fundamentally pretty simple. I'm still in favor of the simple current approach (modulo bikeshedding on some details). But I'd like to better understand why you favor the postinst approach over the build-time approach. 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/20140516101047.40e05...@anarchist.wooz.org
Re: wheel support for Debian?
On May 15, 2014, at 11:38 PM, Scott Kitterman wrote: >Shouldn't it be singular? Each package provides a wheel, not several wheels >(and I'd name the location the same for consistency). I thought about this. True, in all current cases there's a single wheel file in the binary package. I wanted to leave open the possibility that a binary package could contain multiple wheels, but I agree that's a weak argument given the scope we're trying to limit here. Two mild reasons I went with plurals in the package name: I think the directory where these get laid down on the file system *should* be plural, since it *will* hold multiple wheels, and I wanted the binary package name to reflect that. Also, since we now have python-wheel and python3-wheel packages, which contain the PyPI wheel package, I thought it was confusing to name the built-wheel packages with the same suffix. E.g. python-wheel and python-urllib3-wheel would by naming appear to have a relationship that they actually don't have. It seemed clearer that the latter would be called python-urllib3-wheels. It's bikeshedding, but anyway that was my rationale for choosing the names I did. 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/20140516101703.6c95d...@anarchist.wooz.org
Proposed policy change to define but discourage Python wheels in Debian
Here is the diff I propose to Debian Python policy, describing our policy on packaging wheels. Cheers, -Barry === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2014-05-12 10:21:25 + +++ debian/python-policy.sgml 2014-05-16 15:23:30 + @@ -32,7 +32,11 @@ Scott Kitterman sc...@kitterman.com - version 0.9.5 + +Barry Warsaw +ba...@debian.org + + version 0.9.6 This document describes the packaging of Python within the @@ -468,6 +472,36 @@ programs included in the same package. + +Wheels + + http://legacy.python.org/dev/peps/pep-0427/"; + name="PEP 427"> + defines a built-package format called "wheels", which is a zip + format archive containing Python code and a "dist-info" metadata + directory, in a single file named with the .whl suffix. As zip + files, wheels containing pure-Python can be put on sys.path and + modules in the wheel can be imported directly by Python's "import" + statement. (Importing extension modules from wheels is not yet + supported as of Python 3.4.) + + The use, building, and inclusion of wheels in binary packages is + strongly discouraged. A very limited set of wheel packages are + available in the archive, but these support the narrow purpose of + providing the Python 3 built-in virtual environment creation + executable pyvenv-3.x, as well as the + within-venv pip executable, in a Debian policy + compliant way. + + Wheels supporting pyvenv and pip are named + with the python- prefix, and the -wheels + suffix, e.g. python-chardet-wheels. When + these binary packages are installed, their .whl files should be + placed in the /usr/share/python-wheels directory. Such wheels + should be built with the --universal flag so as to generate + wheels compatible with both Python 2 and Python 3. + + Module Package Names signature.asc Description: PGP signature
Re: Proposed policy change to define but discourage Python wheels in Debian
On Friday, May 16, 2014 11:28:45 Barry Warsaw wrote: > Here is the diff I propose to Debian Python policy, describing our policy on > packaging wheels. > > Cheers, > -Barry > > === modified file 'debian/python-policy.sgml' > --- debian/python-policy.sgml 2014-05-12 10:21:25 + > +++ debian/python-policy.sgml 2014-05-16 15:23:30 + > @@ -32,7 +32,11 @@ > Scott Kitterman > sc...@kitterman.com > > - version 0.9.5 > + > +Barry Warsaw > +ba...@debian.org > + > + version 0.9.6 > > > This document describes the packaging of Python within the > @@ -468,6 +472,36 @@ > programs included in the same package. > > > + > +Wheels > + > + http://legacy.python.org/dev/peps/pep-0427/"; > + name="PEP 427"> > + defines a built-package format called "wheels", which is a zip > + format archive containing Python code and a "dist-info" metadata > + directory, in a single file named with the .whl suffix. As zip > + files, wheels containing pure-Python can be put on sys.path and > + modules in the wheel can be imported directly by Python's > "import" + statement. (Importing extension modules from wheels is > not yet + supported as of Python 3.4.) > + > + The use, building, and inclusion of wheels in binary packages is > + strongly discouraged. A very limited set of wheel packages are > + available in the archive, but these support the narrow purpose of > + providing the Python 3 built-in virtual environment creation + >executable pyvenv-3.x, as well as the > + within-venv pip executable, in a Debian policy > + compliant way. > + > + Wheels supporting pyvenv and pip are > named + with the python- prefix, and the > -wheels + suffix, e.g. > python-chardet-wheels. When + these binary > packages are installed, their .whl files should be + placed in the > /usr/share/python-wheels directory. Such wheels + should be built > with the --universal flag so as to generate + wheels > compatible with both Python 2 and Python 3. > + > + > > Module Package Names > I good start. I think "strongly discouraged" is too weak. I think it should be a must not except the packages needed for pyvenv/pip and all those packages should be explicitly listed (so that it takes an update to policy to make it policy OK to add more wheels. Scott K signature.asc Description: This is a digitally signed message part.
Re: Proposed policy change to define but discourage Python wheels in Debian
On 16.05.2014 17:53, Scott Kitterman wrote: > On Friday, May 16, 2014 11:28:45 Barry Warsaw wrote: >> Here is the diff I propose to Debian Python policy, describing our policy on >> packaging wheels. >> >> Cheers, >> -Barry >> >> === modified file 'debian/python-policy.sgml' >> --- debian/python-policy.sgml2014-05-12 10:21:25 + >> +++ debian/python-policy.sgml2014-05-16 15:23:30 + >> @@ -32,7 +32,11 @@ >> Scott Kitterman >> sc...@kitterman.com >> >> - version 0.9.5 >> + >> +Barry Warsaw >> +ba...@debian.org >> + >> + version 0.9.6 >> >> >> This document describes the packaging of Python within the >> @@ -468,6 +472,36 @@ >>programs included in the same package. >> >> >> + >> +Wheels >> + >> + http://legacy.python.org/dev/peps/pep-0427/"; >> + name="PEP 427"> >> + defines a built-package format called "wheels", which is a zip >> + format archive containing Python code and a "dist-info" metadata >> + directory, in a single file named with the .whl suffix. As zip >> + files, wheels containing pure-Python can be put on sys.path and >> + modules in the wheel can be imported directly by Python's >> "import" + statement. (Importing extension modules from wheels is >> not yet + supported as of Python 3.4.) >> + >> + The use, building, and inclusion of wheels in binary packages is >> + strongly discouraged. A very limited set of wheel packages are >> + available in the archive, but these support the narrow purpose of >> + providing the Python 3 built-in virtual environment creation + >>executable pyvenv-3.x, as well as the >> + within-venv pip executable, in a Debian policy >> + compliant way. >> + >> + Wheels supporting pyvenv and pip are >> named + with the python- prefix, and the >> -wheels + suffix, e.g. >> python-chardet-wheels. When + these binary >> packages are installed, their .whl files should be + placed in the >> /usr/share/python-wheels directory. Such wheels + should be built >> with the --universal flag so as to generate + wheels >> compatible with both Python 2 and Python 3. >> + >> + >> >> Module Package Names >> > > I good start. I think "strongly discouraged" is too weak. I think it should > be a must not except the packages needed for pyvenv/pip and all those > packages > should be explicitly listed (so that it takes an update to policy to make it > policy OK to add more wheels. > I think the text should contain why it is "strongly discouraged". It is not clear to me from this text. -- 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/53764865.4050...@googlemail.com
Re: Proposed policy change to define but discourage Python wheels in Debian
Second draft. -Barry === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2014-05-12 10:21:25 + +++ debian/python-policy.sgml 2014-05-16 18:08:52 + @@ -32,7 +32,11 @@ Scott Kitterman sc...@kitterman.com - version 0.9.5 + +Barry Warsaw +ba...@debian.org + + version 0.9.6 This document describes the packaging of Python within the @@ -468,6 +472,45 @@ programs included in the same package. + +Wheels + + http://legacy.python.org/dev/peps/pep-0427/"; + name="PEP 427"> + defines a built-package format called "wheels", which is a zip + format archive containing Python code and a "dist-info" metadata + directory, in a single file named with the .whl suffix. As zip + files, wheels containing pure-Python can be put on sys.path and + modules in the wheel can be imported directly by Python's "import" + statement. (Importing extension modules from wheels is not yet + supported as of Python 3.4.) + + In general, packages must not build or provide wheels. They are + redundant to the established way of providing Python libraries to + Debian users, take no advantage of distro-based tools, and are less + convenient to use. E.g. they must be explicitly added to sys.path, + cannot be easily grepped, and stack traces through zips are more + difficult to debug. + + A very limited set of wheel packages are available in the archive, + but these support the narrow purpose of providing the Python 3 + built-in virtual environment creation + executable pyvenv-3.x, as well as the + within-venv pip executable, in a Debian policy + compliant way. The set of packages providing wheels for this + purpose are (by source package name): chardet, distlib, html5lib, + python-colorama, python-setuptools, python-urllib3, requests, six, + urllib3. + + Wheels supporting pyvenv and pip are named + with the python- prefix, and the -wheels + suffix, e.g. python-chardet-wheels. When these + binary packages are installed, their .whl files must be placed in + the /usr/share/python-wheels directory. Such wheels must be built + with the --universal flag so as to generate wheels + compatible with both Python 2 and Python 3. + + Module Package Names signature.asc Description: PGP signature
Re: Proposed policy change to define but discourage Python wheels in Debian
On Friday, May 16, 2014 14:09:26 Barry Warsaw wrote: > Second draft. > -Barry > > === modified file 'debian/python-policy.sgml' > --- debian/python-policy.sgml 2014-05-12 10:21:25 + > +++ debian/python-policy.sgml 2014-05-16 18:08:52 + > @@ -32,7 +32,11 @@ > Scott Kitterman > sc...@kitterman.com > > - version 0.9.5 > + > +Barry Warsaw > +ba...@debian.org > + > + version 0.9.6 > > > This document describes the packaging of Python within the > @@ -468,6 +472,45 @@ > programs included in the same package. > > > + > +Wheels > + > + http://legacy.python.org/dev/peps/pep-0427/"; > + name="PEP 427"> > + defines a built-package format called "wheels", which is a zip > + format archive containing Python code and a "dist-info" metadata > + directory, in a single file named with the .whl suffix. As zip > + files, wheels containing pure-Python can be put on sys.path and > + modules in the wheel can be imported directly by Python's > "import" + statement. (Importing extension modules from wheels is > not yet + supported as of Python 3.4.) > + > + In general, packages must not build or provide wheels. They are > + redundant to the established way of providing Python libraries to > + Debian users, take no advantage of distro-based tools, and are > less + convenient to use. E.g. they must be explicitly added to > sys.path, + cannot be easily grepped, and stack traces through > zips are more + difficult to debug. > + > + A very limited set of wheel packages are available in the > archive, + but these support the narrow purpose of providing the > Python 3 + built-in virtual environment creation > + executable pyvenv-3.x, as well as the > + within-venv pip executable, in a Debian policy > + compliant way. The set of packages providing wheels for this > + purpose are (by source package name): chardet, distlib, html5lib, > + python-colorama, python-setuptools, python-urllib3, requests, > six, + urllib3. > + > + Wheels supporting pyvenv and pip are > named + with the python- prefix, and the > -wheels + suffix, e.g. > python-chardet-wheels. When these + binary > packages are installed, their .whl files must be placed in + the > /usr/share/python-wheels directory. Such wheels must be built + > with the --universal flag so as to generate wheels + > compatible with both Python 2 and Python 3. > + > + > > Module Package Names > Seems reasonable to me. Let's let it bake for several days so everyone has a chance to chime in. Scott K signature.asc Description: This is a digitally signed message part.
Re: restarting services after security upgrades in pure-Python modules?
* Paul Wise , 2014-05-16, 14:17: Anyone know if it is possible to detect processes that are using old versions of pure-Python modules after security upgrades to them? needrestart(1) attempts to do that, but I doubt it works well: https://sources.debian.net/src/needrestart/0.9-1/perl/lib/NeedRestart/Interp/Python.pm -- Jakub Wilk -- 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/20140516203454.ga5...@jwilk.net
