Re: wheel support for Debian?
[Matthias Klose, 2014-05-19] > python-wheel.wheel > > becomes clear ... and it's the singular. IMO -wheel or -wheels is a better name - it's clear that the second "wheel" is not part of namespace this way. We already have -doc, -ext, etc. for special packages, lets keep "-" for wheels as well -- 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/20140519094527.gi4...@sts0.p1otr.com
Re: wheel support for Debian?
[Barry Warsaw, 2014-05-16] > 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? * I don't want to promote .whl, .egg or anything else that is not even remotely comparable to .rpm or .deb, * I don't think we should force admins to learn anything other than apt-get/deb. We should burn every egg, whl, gem, etc. that is not in /usr/local or in ~/.local/ with fire! We know whls are zip files, but admins do not have to know that. If there's security issue (not yet fixed by Debian), do we want to force them to learn how to change a file inside .whl file? They have better things to do, * I don't think we should force maintainers to do changes in their packages if it's not really needed, (not to mention additional work for ftpmasters) * I don't think we should add redundant files to the archive if it doesn't really gain that much > 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 if wheel specification is so unclear that we have to use 3rd party library (setuptools) to generate them, that worries me as well > 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 we know what has to go to .deb package, we know exactly which files are needed, we already provide egg-info/dist-info directories. If whls need more than this, why not ship only these additional files instead of complete .whl files? > 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. please at least unpack these wls files so that admins don't have to figure out what to do with them if they want to apply a patch from upstream -- 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/20140519101939.gj4...@sts0.p1otr.com
Re: wheel support for Debian?
Am 19.05.2014 12:19, schrieb Piotr Ożarowski: > please at least unpack these wls files so that admins don't have to > figure out what to do with them if they want to apply a patch from > upstream no, you don't gain anything by this. we don't unpack jar files either. Matthias -- 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/5379e091.5060...@debian.org
Re: wheel support for Debian?
* Matthias Klose , 2014-05-19, 12:44: we don't unpack jar files either. Fortunately, we don't have to mimic all the Java misfeatures. -- 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/20140519111953.gc8...@jwilk.net
Re: wheel support for Debian?
Unpacking the Wheel files will trigger pip to see them as installed and it will attempt to uninstall them if it needs to. If they are going to be unpacked it’ll need to have the .dist-info directory removed from the unpacked locations in order to prevent that from happening. On May 19, 2014, at 7:19 AM, Jakub Wilk wrote: > * Matthias Klose , 2014-05-19, 12:44: >> we don't unpack jar files either. > > Fortunately, we don't have to mimic all the Java misfeatures. > > -- > 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/20140519111953.gc8...@jwilk.net > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: wheel support for Debian?
On May 19, 2014, at 12:19 PM, Piotr Ożarowski wrote: >* I don't want to promote .whl, .egg or anything else that is not even > remotely comparable to .rpm or .deb, In fact, the second draft of the policy that I posted explicitly prohibits wheels except in some specific, described cases. >* I don't think we should force admins to learn anything other than > apt-get/deb. We should burn every egg, whl, gem, etc. that is not in > /usr/local or in ~/.local/ with fire! > We know whls are zip files, but admins do not have to know that. > If there's security issue (not yet fixed by Debian), do we want to > force them to learn how to change a file inside .whl file? They have > better things to do, It should be rare to nonexistent for admins, or almost anyone, to *have* to know about the details of wheels. Remember, the wheels are only there for pip to function properly *inside* a virtual environment. Splitting out pythonX.Y-venv into a separate binary package means that none of this gets installed by default. Only people developing libraries and applications with Python will care at all, and I would mostly expect them to at least be able to understand wheels if necessary (such developers might even be building them themselves). >* I don't think we should force maintainers to do changes in their > packages if it's not really needed, > (not to mention additional work for ftpmasters) The additional ftpmasters work should happen once. All of the required packages are under DPMT maintenance, except six (now to be co-maintained by Colin and myself), distlib and setuptools (doko), and colorama (which has only seen NMUs after the initial upload and for which I have started the MIA process, intending to adopt it into DPMT). And of course python3.4. There's a README.venv in my python3.4 patch which describes exactly how the whole thing hangs together. Most people won't care, they'll just apt-get install python3-venv and be done with it. >* I don't think we should add redundant files to the archive if it > doesn't really gain that much I think it does gain us things. I gains simplicity of packaging, since all the pieces needed already exist upstream and are well tested, so the packaging changes are just a command and a .install file. It's also highly discoverable since the command is right there in the rules file. It's easier to debug. It's code we don't have to write, debug, and maintain. It means the delta for python3.4 is smaller, with more of a chance of getting those changes upstreamed. >if wheel specification is so unclear that we have to use 3rd party >library (setuptools) to generate them, that worries me as well PEP 427 describes the wheel format in detail. We could craft them ourselves, although I'm not sure why we'd want to when bdist_wheel already does it. Using setuptools just makes it all easier. >> 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 > >we know what has to go to .deb package, we know exactly which files are >needed, we already provide egg-info/dist-info directories. If whls need >more than this, why not ship only these additional files instead of >complete .whl files? I have a working stack. We don't yet have working code for building the wheels on the fly. A practical solution would be to adopt the current approach now to fix a real bug that causes our users headaches. You can always work on the postinst wheel building code in the meantime and propose changing over to it if it proves to be clearly better. At least it wouldn't be a transition on the order of python-central or -support :). I don't favor the postinst approach, so I'm not volunteering to do that work. I also don't think we should hold up resolution of this issue. This isn't a permanent change we'll regret three years from now. 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/20140519095522.49384...@anarchist.wooz.org
Re: wheel support for Debian?
On May 19, 2014, at 07:21 AM, Donald Stufft wrote: >Unpacking the Wheel files will trigger pip to see them as installed and it >will attempt to uninstall them if it needs to. If they are going to be >unpacked it’ll need to have the .dist-info directory removed from the >unpacked locations in order to prevent that from happening. .whl files are so much simpler. If you want to use unpacked wheels, you'll have to modify more logic in upstream python3.4 and pip. The deltas from upstream will be larger and less likely to be adopted upstream. -Barryu signature.asc Description: PGP signature
Re: wheel support for Debian?
On May 19, 2014, at 01:33 AM, Matthias Klose wrote: >I would like to avoid different wheel directories in /usr/share, so if the >name of the wheel encodes the python version, then they probably can live in >the same directory. PEP 427 provides a tagging scheme that allows differentiation in the file name. Universal wheels will be tagged "py2-py3-none-any" meaning they work for any Python 2 or 3 version, have no ABI tag (i.e. they are pure Python) and work on any platform. If we had to, we could tag things e.g. py34-cp34m-linux_x86_64 which could live along side a py27-none-any wheel. Think of it as PEP 3147/3149 for wheel files. We gain the same single-directory benefits here too. >The GNUstep apps are packaged as .app, so why not use .wheel? then even > > python-wheel.wheel > >becomes clear ... and it's the singular. On May 19, 2014, at 11:45 AM, Piotr Ożarowski wrote: >[Matthias Klose, 2014-05-19] >> python-wheel.wheel >> >> becomes clear ... and it's the singular. > >IMO -wheel or -wheels is a better name - it's clear that the second >"wheel" is not part of namespace this way. We already have -doc, -ext, >etc. for special packages, lets keep "-" for wheels as well I also favor - instead of . Maybe we could use -whl as a package name suffix. It's a little less clear as to its purpose (e.g. in a package name search listing for html5lib), but it mimics the file extension of the things it contains. It's also shorter and avoids the singular/plural distinction. Highly unlikely that there will be a package name clash in the future. I don't expect to see py.whl-whl any time soon. :) 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/20140519100658.60a02...@anarchist.wooz.org
Re: wheel support for Debian?
On May 19, 2014, at 02:12 PM, Robert Collins wrote: >Did you consider using python-wheels-urllib3 ? I didn't because usually we use a suffix for related packages, as Piotr pointed out, e.g. python-foo-doc, python-foo-bin, python-foo-common, etc. -Barry signature.asc Description: PGP signature
Re: wheel support for Debian?
On May 19, 2014 9:55:22 AM EDT, Barry Warsaw wrote: >On May 19, 2014, at 12:19 PM, Piotr Ożarowski wrote: ... >>* I don't think we should force maintainers to do changes in their >> packages if it's not really needed, >> (not to mention additional work for ftpmasters) > >The additional ftpmasters work should happen once. ... I'm an FTP Assistant. I don't mind taking care of the FTP work once we have an agreed plan. Scott K -- 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/5234fa6f-d1f3-4987-8c8d-88af9440a...@email.android.com
Re: wheel support for Debian?
Ditto, I can help in the same capacity. On Mon, May 19, 2014 at 10:39 AM, Scott Kitterman wrote: > On May 19, 2014 9:55:22 AM EDT, Barry Warsaw wrote: >>On May 19, 2014, at 12:19 PM, Piotr Ożarowski wrote: > ... >>>* I don't think we should force maintainers to do changes in their >>> packages if it's not really needed, >>> (not to mention additional work for ftpmasters) >> >>The additional ftpmasters work should happen once. > ... > > I'm an FTP Assistant. I don't mind taking care of the FTP work once we have > an agreed plan. > > Scott K > > > -- > 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/5234fa6f-d1f3-4987-8c8d-88af9440a...@email.android.com > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/cao6p2qs_qptkvtbrr1dqh0a9w67schvolj2oh93sqr__9mo...@mail.gmail.com
Request to join python-apps
Hei, I was on the #debian-python IRC channel on irc.efnet.org earlier. I want to join the python-apps team and have already sent a request in the web interface on alioth. My intention is to adopt postr[0] within the team and maintain it together with Yoann Gauthier. Is there any official process to adopting a package within a team after joining? [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711833 -- 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/20140519190548.ga2...@gmail.com
Re: Join the Team
On Sun, May 18, 2014 at 5:28 AM, Hugo Lefeuvre wrote:
> Hi Vincent,
>
>> Welcome (in advance) to the team! Please let me know if you're
>> subscribed to the list, so I can stop cc-ing you.
>
> Thank you ! I've made it.
>
> I've already followed Lucas Nussbaum's tutorial for a week (which is
> very interesting), but I made a mistake in my latest email: With
> 'I have no skills in Debian packaging', I wanted to say that I had no
> experience in maintaining Debian packages. :)
>
>> Great! You'll have to be accepted to the DPMT/PAPT in alioth first
>> before you'll have commit access to the svn repos. If you need
>> somewhere to upload your packages prior to asking for a review, I
>> suggest using mentors.debian.net [3].
>
> I'll upload my patch for the kupfer package in mentors.debian.net. I've
> already an account (with the username hugo6390).
For the purposes of this review, I'm going to assume that what you
uploaded is this source package (since you didn't give a direct link):
http://mentors.debian.net/debian/pool/main/k/kupfer/kupfer_0+v208-3.dsc
- Your new upload has to have a different version number than past
uploads. kupfer/0+v208-3 was already uploaded on 2013-12-19 by Luca
Falavigna; you should instead be using version 0+v208-4 instead.
- Please revert your changes to debian/watch; your watch file doesn't
work (404; use uscan(1) to verify).
- Please revert your changes to Vcs-{Svn,Browser} in debian/control:
the original Vcs-* links are correct and are the canonical Vcs links
that you should be using in d/control. [1]
- Please revert the rest of your changes to debian/control (having a
single build-dep/dependency on each line makes it much easier to see
what changed with a diff in between uploads; wrap-and-sort(1) from the
"devscripts" package helps to format debian/control like what it is
currently. Don't "un-"wrap-and-sort the package...
- Please set DPMT as maintainer, and you as uploader (instead of the
other way around).
The only remaining change now is your removal of a number of patches
applied to the package (almost every other change you made is bogus
and should be reverted, sorry). A few comments about this:
- Please document this in debian/changelog
- Why did you remove these patches? Include a brief rationale in d/changelog.
Regards,
Vincent
[1] http://lintian.debian.org/tags/vcs-field-not-canonical.html
--
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_tcmk2lzqmsnn7c4jhwxy4jw+d_9d6uheyj5x-orf7o...@mail.gmail.com
Re: Request to join python-apps
Hi Alexander, On Mon, May 19, 2014 at 12:05 PM, Alexander Alemayhu wrote: > Hei, > > I was on the #debian-python IRC channel on irc.efnet.org earlier. I want to irc.efnet.org? Don't you mean OFTC (or its alias irc.debian.org)? > join the python-apps team and have already sent a request in the web interface > on alioth. My intention is to adopt postr[0] within the team and maintain it > together with Yoann Gauthier. Is there any official process to adopting a > package within a team after joining? > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711833 If you intend to join the PAPT, please create an account on Alioth [1] and join the team there in order to get commit access to our svn repos; more info at [2]. I suggest uploading the package to mentors.debian.net (definitely read [3] first) as well to make it easier to review your package. Regards, Vincent [1] https://alioth.debian.org/ [2] https://wiki.debian.org/Teams/PythonAppsPackagingTeam [3] http://mentors.debian.net/intro-maintainers -- 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_tB7+m2=2L7Z4HhHmypRu=y5jz1jnReYtgss3ixM4=x...@mail.gmail.com
