Re: [Distutils] A process for removal of PyPi entries
On 03/06/2013 03:43, Noah Kantrowitz wrote: Some people are saying files uploaded vs. downloadable packages. I don't like the files uploaded criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control. Sorry, if you haven't had time to follow lately we have already begun deprecating this system. I hope you're misunderstanding what pje is saying; this isn't about hosting distributions elsewhere, this is about having a PyPI listing for a project that is under development but it hasn't got to the point where it's sensible for a release to be made. Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name distutils on PyPI, before its first release. ;-) If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'. ...or different definitions of 'software quality' ;-) Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea. cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Jun 3, 2013, at 2:22 AM, Chris Withers ch...@simplistix.co.uk wrote: On 03/06/2013 03:43, Noah Kantrowitz wrote: Some people are saying files uploaded vs. downloadable packages. I don't like the files uploaded criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control. Sorry, if you haven't had time to follow lately we have already begun deprecating this system. I hope you're misunderstanding what pje is saying; this isn't about hosting distributions elsewhere, this is about having a PyPI listing for a project that is under development but it hasn't got to the point where it's sensible for a release to be made. Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name distutils on PyPI, before its first release. ;-) If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'. ...or different definitions of 'software quality' ;-) Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea. Unless I missed it I don't think I've seen *anyone* suggest that projects where the authors appear to actually have plans to use the name have the name yanked out from underneath them. cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On 03/06/2013 06:56, Lennart Regebro wrote: On Mon, Jun 3, 2013 at 4:21 AM, PJ Ebyp...@telecommunity.com wrote: On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebrorege...@gmail.com wrote: On Sat, Jun 1, 2013 at 9:20 PM, Paul Moorep.f.mo...@gmail.com wrote: I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email) This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted. Some people are saying files uploaded vs. downloadable packages. I don't like the files uploaded criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control. Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name distutils on PyPI, before its first release. ;-) Absolutely. Which gets us back to the nothing to download, no way of contacting criteria I originally proposed. :-) +1 :-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On 03/06/2013 08:13, Donald Stufft wrote: If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'. ...or different definitions of 'software quality' ;-) Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea. Unless I missed it I don't think I've seen *anyone* suggest that projects where the authors appear to actually have plans to use the name have the name yanked out from underneath them. ...in that case, I'm happy to find out I have misunderstood :-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
Hi Jim, On Sun, Jun 02, 2013 at 11:25 -0400, Jim Fulton wrote: On Sat, Jun 1, 2013 at 3:21 PM, holger krekel hol...@merlinux.eu wrote: On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. I've heart this sentiment before, but would like to read more clearly stated problems. I thought the problem was pretty clear: name collisions. In theory yes, but is a practical problem? Similar to Donald, so far i didn't find myself or hear much from other people that they have problems finding good pypi names. We have some 30K names registered with PyPI i think -- and many top level DNS entries have millions of names. So the numbers don't clearly imply we have a scaling problem. There's a parallel thread on how to detect and reclaim names that are taken and unused. I think if we had a more systematic way of naming packages, this wouldn't be an issue. It might still be an issue. ... Everyone could continue to push non-namespaced (flat) packages to pypi like now but the names couldn't take the form of namespaced ones. I'm not sure what you're suggesting here. Are you saying someone could publish a package named: zc, bit not zc.foo? Or are you saying that publication of a package named bar would prevent someone from creating a bar namespace, and the other way around? I'd think that once a group registers a X namespace and it is accepted it would give control to registering any X.* packages to that group. As a pre-condition there shouldn't be any bare X package existing i guess. Clearly, the exact semantics/process would need to be thought out. I'd like to base further discussion on actual PEP drafts with a proper statement of practical problems. What i personally would consider a practical problem is this: As a company/community we have already N packages and we want to communicate our users through pypi names that using the namespace 'XY.' will always get them software that we have screened/reviewed/released ourselves. But currently there is no way to prevent others from releasing ZY. prefixed software. cheers, holger Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On 06/03/2013 09:35 AM, holger krekel wrote: On Sun, Jun 02, 2013 at 13:51 -0400, Tres Seaver wrote: On 06/02/2013 03:10 AM, holger krekel wrote: Somewhat proper import namespacing is only available with very recent python versions which still have a long way to become mainstream. I don't understand this claim at all. W'eve had packages in python for fifteen years, and extensible namespace-package support in one form or another for eight. The fact that the Python 3.3 adds support for a new spelling doesn't mean they are a new feature. I stand corrected. To be honest, i didn't consider the setuptools extensible namespace support a proper solution but indeed it exists and is used. FWIW, the small scientific libraries associated with the SciPy ecosystem was gathered under the scikits umbrella, so that you had scikits.learn, scikits.image, and so on. Eventually the setuptools pain made them decide to drop that and name themselves sklearn, skimage. Dag Sverre ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Mon, Jun 3, 2013 at 3:35 AM, holger krekel hol...@merlinux.eu wrote: On Sun, Jun 02, 2013 at 13:51 -0400, Tres Seaver wrote: On 06/02/2013 03:10 AM, holger krekel wrote: Somewhat proper import namespacing is only available with very recent python versions which still have a long way to become mainstream. I don't understand this claim at all. W'eve had packages in python for fifteen years, and extensible namespace-package support in one form or another for eight. The fact that the Python 3.3 adds support for a new spelling doesn't mean they are a new feature. I stand corrected. To be honest, i didn't consider the setuptools extensible namespace support a proper solution but indeed it exists and is used. Before the setuptools namespace support, there was the pkgutil module in the standard library. Setuptools' system only added support for zipped packages. Python's current package system allows you to manipulate a package's path, used to find modules and sub-packages in the package. The Zope project used this mechanism for years support the Zope Products namespace package. The pkgutils module, and later setuptools' mechanism just simplified this. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/02/2013 11:42 AM, Jason R. Coombs wrote: I'm pleased to announce the official release of Setuptools 0.7, now available for download from the project page https://bitbucket.org/pypa/setuptools . Nothing has changed from the 0.7b4 pre-release. This is the version that will be uploaded to PyPI after we work out the technique to deploy to PyPI without interfering with the setuptools 0.6 releases. For convenience, I've also added experimental .msi installers for Windows for Python 3.3 and Python 2.7. Work may continue on these in the future, but as the documentation states, the recommended installation procedure is to use ez_setup.py. To install this latest release, follow the canonical install instructions (using ez_setup.py), but direct the script to use bitbucket instead of PyPI: Maybe I'm missing something, but where is the 'ez_zetup.py' script hosted? It isn't present in the bitbucket downloads directlry. https://bitbucket.org/pypa/setuptools/downloads/ Maybe linking to or recapitulating the canonical install instructions here would help diespel confusion. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGsj78ACgkQ+gerLs4ltQ4JqQCgrSWCnecjtDTk5BrupmQEEUkB l/YAn3qY9uxe1Fb4PXPpOnIV0wgWy4Rd =/7uv -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 08:44 AM, Tres Seaver wrote: On 06/02/2013 11:42 AM, Jason R. Coombs wrote: I'm pleased to announce the official release of Setuptools 0.7, now available for download from the project page https://bitbucket.org/pypa/setuptools . Nothing has changed from the 0.7b4 pre-release. This is the version that will be uploaded to PyPI after we work out the technique to deploy to PyPI without interfering with the setuptools 0.6 releases. For convenience, I've also added experimental .msi installers for Windows for Python 3.3 and Python 2.7. Work may continue on these in the future, but as the documentation states, the recommended installation procedure is to use ez_setup.py. To install this latest release, follow the canonical install instructions (using ez_setup.py), but direct the script to use bitbucket instead of PyPI: Maybe I'm missing something, but where is the 'ez_zetup.py' script hosted? It isn't present in the bitbucket downloads directlry. https://bitbucket.org/pypa/setuptools/downloads/ Maybe linking to or recapitulating the canonical install instructions here would help diespel confusion. I tried looking at the README on Bitbucket: https://bitbucket.org/pypa/setuptools/#rst-header-installation-instructions but that points to an invalid URL for 'ez_setup.py': https://bitbucket.org/pypa/setuptools/raw/0.7.1/ez_setup.py The version here: https://bitbucket.org/pypa/setuptools/raw/0.7/ez_setup.py points to PyPI for the DEFAULT_URL. During the beta, I think we need to have a version ov 'ez_setup.py' available which points to the Bitbucket download page, rather than PyPI. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGskRMACgkQ+gerLs4ltQ45IQCdEFrOuCszGKStzKxKPdN2vPd/ /fMAn2j5mdBhE4PthXlG/wVVqv1ztoz9 =kFhy -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 03.06.2013 14:44, schrieb Tres Seaver: Maybe I'm missing something, but where is the 'ez_zetup.py' script hosted? It isn't present in the bitbucket downloads directlry. https://bitbucket.org/pypa/setuptools/downloads/ Maybe linking to or recapitulating the canonical install instructions here would help diespel confusion. It's here https://bitbucket.org/pypa/setuptools/src . Another concern: ez_zetup.py neither uses https to download setuptools nor contains checksums anymore. setuptools 0.6 at least used to validate the download with a known MD5 checksum. I suggest that SHA-1 hashsums are added to ez_setup.py. SHA-2 is not supported by Python 2.5. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRrJRAAAoJEMeIxMHUVQ1FVicQAIc7F52TWwIK6WOPGpvimozN fe9JnJI0nCtgCgaplOnneS9JR82GJOOX1vOWJyapo/q2xGiT+79gHV38vkxv50f8 C22B2sfA5K4kgQutqNnZVYzwVFb5f6idR8lTE8D2Zkwt6CUsEyeJlAMfG8rkL903 UcjSDgsTcPFsGXPDvkw9vfirrJ1aQQcVpbK4NlN4Xn5uGN5vpvxmVvBrAYRZ/1nX L9l81I/1njCJmNgXRxOGdPZAxZtkrzgW1tNc/hZxKNeXhN4mO7RQwbYwjDtCcy8F gmxeo4jK/nFrGP71bQTH55erFAIva8rWPl7J3M5W2l9fnrn4Iv80oScv5wSOAcW6 EP53pS1RPT1IEtHI3TyADicqz8pyuj3aLSiih0H62YhBLIDWJ/WZ4PAWoL2hbSXN aveoqqpjXVrjH+UNhs1Zy27ns8AY2sgwKiyeOwji1U/uICAl9hsjmDZLg6110z71 q3arNPQOdnRdLUYO8uX6n4BFdjlqtv070Z6plXeOHQSpMC4Yzypz4b3l+6dvc00p hFcJpmecvaS052QGRANRy+rqKHJ7AgGd39LjKgFetQ56mNWLAPfqNafPqxRit8y7 jyCjehaNjFHX5VImxK3mU+dl+q2+eCNbZ1BA+YZ/aWlqlZ8FD+6LwNMuAVy5RqZ3 SGV/gwwGdufzcMbzEEJv =GLKv -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:04 AM, Christian Heimes wrote: It's here https://bitbucket.org/pypa/setuptools/src . That version points to PyPI as the location, and wants to install version 0.7.1. Until 0.7 is pushed to PyPI, we need an ez_setup.py available which points to the bitbucket download page. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGslpwACgkQ+gerLs4ltQ7IRwCfS1suMO0YzA9P1iTvNDDd+Hrm myoAn0uqw7cyOuqqaHj/DaXO5sRA53BY =rFuY -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
On Sun, Jun 2, 2013 at 11:42 AM, Jason R. Coombs jar...@jaraco.com wrote: I’m pleased to announce the official release of Setuptools 0.7, now available for download from the project page. Nothing has changed from the 0.7b4 pre-release. This is the version that will be uploaded to PyPI after we work out the technique to deploy to PyPI without interfering with the setuptools 0.6 releases. For convenience, I’ve also added experimental .msi installers for Windows for Python 3.3 and Python 2.7. Work may continue on these in the future, but as the documentation states, the recommended installation procedure is to use ez_setup.py. To install this latest release, follow the canonical install instructions (using ez_setup.py), but direct the script to use bitbucket instead of PyPI: python ./ez_setup.py --download-base=https://bitbucket.org/pypa/setuptools/downloads/ I’ll send another announcement when the official release has been uploaded to PyPI and the ez_setup.py script can be used directly. Thank you Jason and PJ for all your work on this. It's maybe a little late to bring this up now, but I wonder if, in a future release, we could deprecate 'ez_setup.py' (venerable though it is) and name it something a little more obvious, like 'setuptools_setup.py'. Despite being longer and including the word 'setup' twice I think it is a great deal more clear what it does. I remember in the past, before I switched to distribute, I got reports from users who were running the ez_setup.py that I included in projects thinking that it was the easy way to install my software. Yes, they should have just read the README that says python setup.py install and makes no mention of ez_setup.py, but nevertheless I can't blame anyone for finding it vague (and maybe even a bit enticing to run). Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:14 AM, Tres Seaver wrote: Until 0.7 is pushed to PyPI, we need an ez_setup.py available which points to the bitbucket download page. As an alternative, we could just go ahead and push out this version to the cheeseshop: AFAICT, it doesn't break stuff (especially compared to the current 0.6 nightly -- see issue #8[1]), and anybody who needs to can pin 'setuptools0.7dev'. [1] https://bitbucket.org/pypa/setuptools/issue/8/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGsqDAACgkQ+gerLs4ltQ5LHQCdHrCQf4rtvumUvROUJLihdEXC YvEAn3MIY3o2YYxm+X42santI6fTtXC+ =hsyB -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [issue150] ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat'
New submission from Tres Seaver: That Hg commit reference dropped the import of 're', which breaks the '_dnsname_to_pat' fallback function. I reported this on bitbucket: https://bitbucket.org/pypa/setuptools/issue/8 and pushed changes for a pull request there: https://bitbucket.org/pypa/setuptools/pull-request/4 but Jason thinks the 0.6 branch is still primarily managed here and in SVN. The bug breaks the zope.org buildouts, which are still using the 0.6 nightlies while the 0.7 release waits in the wings. -- assignedto: pje messages: 721 nosy: pje, tseaver priority: urgent status: unread title: ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat' ___ Setuptools tracker setupto...@bugs.python.org http://bugs.python.org/setuptools/issue150 ___ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary Wheels and universal builds on OS-X
On Fri, May 31, 2013 at 3:38 PM, Daniel Holth dho...@gmail.com wrote: Wheel already supports compound tags. Just like py2.py3-none-any a tag Is this from PEP 425? It's still a little unclear to me exactly how those tags are to be used, but, yes, this seems to be the right direction. py3-none-x86.ppc (with real platform names) would work. Does that make sense for Mac? hmm, for one, Im confused about the Python Tag vs. the ABI Tag vs. the Platform Tag -- I guess these all get mushed together in the filename? but a few issues anyway: it looks like the platform tag has the OS and a architecture in one, so would a universal bild on the mac be: macosx_10_3_i386.ppc or macosx_10_3_i386.macosx_10_3_ppc I'm thinking the latter, though it gets pretty wordy: A potential full name: my_package-3_2-cp27-cp27-macosx_10_3_i386.macosx_10_3_ppc.whl (Im a little confused about python version tag vs. ABI tag, in the case of a compiled extension...) But a potential confusion -- in this case, having two platform tags indicates that _both_ are present, rather than one thing that works with either. Maybe that would always be the case with platform. So if that's how the wheel is specified, we still need the other side of the process: Installing: A universal macpython binary needs to know that it is universal (distutils.util.get_platform() returns only the currently running version). Once that is know, the installer needs to make some choice: If a matching universal binary is found -- use it If a non-universal binary is found that matches the currently running python -- then what? install it with a warning? raise an exception? -Chris On May 31, 2013 6:30 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be universal -- what this means is that they have more than one binary architecture embedded in a single file; the system selects the right one at run time. Both executables and dynamic libraries can be universal. In theory, an universal binary can currently contain up to 4 architectures: 32+64 bit PPC and 32+64bit x86 In practice, 64 bit PPC was never broadly used, and 32bit PPC is fading fast. Nevertheless, both 32 and 64 Intel systems are pretty common, and who knows what there may be in the future (you never know with Apple...) The binary builds of Python served up on the python.org web site have supported universal builds for years -- currently there are two options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it turns out it's hard to support both up to date x86_64 and PPC with the same compiler. In these builds, the configuration is set up so that distutils will build universal extensions that match the architectures included in the builds. This makes it pretty easy to build binary packages, and/or full app distributions (py2app) that are universal as well. setuptools' easy_install supports binary eggs, but always choked on universal builds -- it didn't know how to identify what matched the system. It would be really nice if future tools could identify and install the correct binary wheels for universal builds. I've taken a look at PEP 427, and see this: platform tag E.g. 'linux_x86_64', 'any'. That looks to me like there is a built-in assumption that a wheel is either specific to a single architecture, or any -- so no way to specify that it may have multiple architectures. So I propose that platform tag allow a list of some sort: ['macosx-10_6_i386', 'macosx_10_6-x86_64'] or, I suppose to keep it simple, a single string: 'macosx_10_6_i386+macosx_10_6_x86_64' or 'macosx_10_6_i386+x86_64' If so, then a binary wheel could be built (and discovered) that supported multiple architectures. Then how would an installer ( pip? ) identify the right one? This is a bit tricky. PEP 425 states: The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore On my system right now, I have 32bitPPC + 32bit i386 universal python, running on an intel system: In [2]: distutils.util.get_platform() Out[2]: 'macosx-10.3-i386' So we may want to patch get_platform() to support universal builds - or add anther function or something -- you may sometimes what to know what you are running right now, and other times want to know how the current python is built. (note that while distutils can build universal binaries, it's not very smart about it -- all is does is grab the compiler and linker flags from the Makefile, which include multiple -arch flags. Even if there is an easy way to query the system, that leaves the question of what to do. If a user wants to intall a package into a universal python, will the
Re: [Distutils] Binary Wheels and universal builds on OS-X
And Ned, Thanks for your offer to write something up -- looking forward to it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary Wheels and universal builds on OS-X
On Mon, Jun 3, 2013 at 12:25 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Fri, May 31, 2013 at 3:38 PM, Daniel Holth dho...@gmail.com wrote:
Wheel already supports compound tags. Just like py2.py3-none-any a tag
Is this from PEP 425? It's still a little unclear to me exactly how
those tags are to be used, but, yes, this seems to be the right
direction.
py3-none-x86.ppc (with real platform names) would work. Does that make sense
for Mac?
hmm, for one, Im confused about the Python Tag vs. the ABI Tag
vs. the Platform Tag -- I guess these all get mushed together in the
filename?
but a few issues anyway: it looks like the platform tag has the OS and
a architecture in one, so would a universal bild on the mac be:
macosx_10_3_i386.ppc
or
macosx_10_3_i386.macosx_10_3_ppc
I'm thinking the latter, though it gets pretty wordy:
A potential full name:
my_package-3_2-cp27-cp27-macosx_10_3_i386.macosx_10_3_ppc.whl
(Im a little confused about python version tag vs. ABI tag, in the
case of a compiled extension...)
But a potential confusion -- in this case, having two platform tags
indicates that _both_ are present, rather than one thing that works
with either. Maybe that would always be the case with platform.
So if that's how the wheel is specified, we still need the other side
of the process:
Installing:
A universal macpython binary needs to know that it is universal
(distutils.util.get_platform() returns only the currently running
version). Once that is know, the installer needs to make some choice:
If a matching universal binary is found -- use it
If a non-universal binary is found that matches the currently running
python -- then what? install it with a warning? raise an exception?
-Chris
The Python Tag is the Python implementation or language version. It
lets you indicate compatibility with only CPython or Jython or PyPy
even if you do not have compiled extensions:
cp27, py27, py2, py3
The ABI tag is the Python ABI. The difference is that it will indicate
debug malloc, unicode:
none (also means we don't know), cp33dm, abi3
The platform tag is the OS+architecture.
They get joined together with a dash '-'.join(python, abi, platform)
For compatibility matching the tags are expanded to the Cartesian
product of the string.split('.') of each of the python, abi, and
platform tags. This is mostly only useful when only one part of the
tag is compound.
http://www.python.org/dev/peps/pep-0425/#compressed-tag-sets
There used to be a rule about preferring packages with the fewest
number of tags in case of a tie but I can't seem to find it now. It's
probably not very important.
If this doesn't work then it might be more useful to invent a tag like
macosx_10_3_universal for some value of universal.
Daniel Holth
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary Wheels and universal builds on OS-X
Darn! this slipped off the list -- I hate it when lists aren't set with the reply-to address as the list... On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dho...@gmail.com wrote: ppc is not completely dead? I have one under my desk, though truth be told, I haven't turned it on in a good while... Which is a good point, of course, we really only have one type of universal build to support, and even that one may be obsolete before too long -- not sure how many 32bit only macs are still around. That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is? can it be platform-dependent? i.e. use a mac-only system call? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary Wheels and universal builds on OS-X
On Mon, Jun 3, 2013 at 6:56 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: Darn! this slipped off the list -- I hate it when lists aren't set with the reply-to address as the list... On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dho...@gmail.com wrote: ppc is not completely dead? I have one under my desk, though truth be told, I haven't turned it on in a good while... Which is a good point, of course, we really only have one type of universal build to support, and even that one may be obsolete before too long -- not sure how many 32bit only macs are still around. That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is? can it be platform-dependent? i.e. use a mac-only system call? Of course. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Fwd: Binary Wheels and universal builds on OS-X
Folks,
Accidentally let this slip off the list...
-Chris
-- Forwarded message --
From: Chris Barker - NOAA Federal chris.bar...@noaa.gov
Date: Mon, Jun 3, 2013 at 1:33 PM
Subject: Re: [Distutils] Binary Wheels and universal builds on OS-X
To: Daniel Holth dho...@gmail.com
On Mon, Jun 3, 2013 at 9:57 AM, Daniel Holth dho...@gmail.com wrote:
A potential full name:
my_package-3_2-cp27-cp27-macosx_10_3_i386.macosx_10_3_ppc.whl
(Im a little confused about python version tag vs. ABI tag, in the
case of a compiled extension...)
The Python Tag is the Python implementation or language version. It
lets you indicate compatibility with only CPython or Jython or PyPy
even if you do not have compiled extensions:
so, in this case, is is right to put cp27 in there twice?
The platform tag is the OS+architecture.
yeah, kind of wish these were separate, but not really a big deal.
For compatibility matching the tags are expanded to the Cartesian
product of the string.split('.') of each of the python, abi, and
platform tags. This is mostly only useful when only one part of the
tag is compound.
http://www.python.org/dev/peps/pep-0425/#compressed-tag-sets
OK -- I think I've got it...
If this doesn't work then it might be more useful to invent a tag like
macosx_10_3_universal for some value of universal.
hmm -- the trick is that universal implies that the binary is, well,
universal, but what t really means is has more than one architecture
in it. In practice, there are only a few combinations likely to see
use, so maybe just defining a few (only two, now, on the python.org
site...) tags makes sense:
macosx_10_3_i386_ppc
and
macosx_10_6_i386_x86_64
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7 final available for download
On Mon, Jun 3, 2013 at 4:29 PM, Tres Seaver tsea...@palladion.com wrote: As an alternative, we could just go ahead and push out this version to the cheeseshop: AFAICT, it doesn't break stuff (especially compared to the current 0.6 nightly -- see issue #8[1]), and anybody who needs to can pin 'setuptools0.7dev'. +1 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Preemptive Apology for Volume of Mail
Just want to apologize to anyone who recently received a lot of mail from me. I realized shortly after I queued all the emails that they should have been grouped by user and not by package. So, I'm sorry. I really am and I feel bad about the amount of mail some of you have received from me. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
