[Distutils] Re: Update PEP 508 to allow version specifiers
On 1/29/19 9:43 AM, Paul Moore wrote: > And when they start adding > version numbers to that (like the OP's package >= 10.0 @ > https://github.com/owner/package.git) I can't even begin to understand > what they think it might mean. (Hence my original request for a better > explanation of the expected semantics!) One might construe the request as a requirement to search the 'releases' or 'tags' page of a github repository, using some to-be-defined heuristic to map the release / tag names onto versioned project names. It wouldn't work for the general case (tags / releases can have arbitrary names). Maybe *worse* is that the tags / releases can be removed / replaced. Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/6XU53MNIFOTANLXCA2GK7VFHBWMH2Q46/
Re: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3
On 12/05/2017 11:39 AM, Dustin Ingram wrote: > Hi all, > > I'd appreciate your feedback on the following Metadata 1.3 PEP. > > The goal here is not to provide a full specification for all fields as > in previous PEPs, but to: > > * Motivate and describe the addition of the new fields or changes to > existing fields; > * Point to the Core Metadata Specifications reference document as the > canonical source for the specification. > > Previous discussions: > * https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html > * https://github.com/python/peps/issues/388 LGTM. Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Entry points: specifying and caching
On 10/19/2017 04:57 PM, Donald Stufft wrote: > Because the feature is unrelated to packaging other than the fact we > currently utilize it for console_scripts. That seems like an odd perspective. Console scripts may be the only bit of entry points which is used *by the packaging system* at installation time, but an system composed of separately-installable packages providing shared services needs some way of querying those services at runtime, which is what all the *other* uses of entry points represent. Having the packaging system register those services at installation time (even if it doesn't care otherwise about them) seems pretty reasonable to me. Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPi’s predictable download url
On 07/25/2017 05:25 PM, Noah Kantrowitz wrote: > >> On Jul 25, 2017, at 2:15 PM, Wes Turner wrote: >> >> >> >> On Tuesday, July 25, 2017, Alexander Belopolsky >> wrote: >> On Tue, Jul 25, 2017 at 4:18 PM, Nick Timkovich >> wrote: >> .. >>> That's because curl is kinda annoying and doesn't follow redirects by >>> default: >>> >>> $ curl -i http://pypi.python.org/pypi/virtualenv/json >>> HTTP/1.1 301 Moved Permanently >>> ... >> >> Well, http://pypi.org/.. which is presumably the home of the latest >> PyPI returns 403: >> >> $ curl -i http://pypi.org/pypi/virtualenv/json >> HTTP/1.1 403 SSL is required >> ... >> >> This suggests that redirects are considered to be legacy and may not >> be supported in the future. >> >> Here are the warehouse routes: >> https://github.com/pypa/warehouse/blob/master/warehouse/routes.py >> >> Why do you need an http to https redirect? > > To explain this: pypi.org is on the HSTS preload list so all major > browsers will automatically use HTTPS for it no matter what. cURL does > not support this feature. Seems like having an unconditional HTTP->HTTPS redirect in place would be a "good neighbor" kind of thing (and belt-and-suspenders, as well). Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Trove classifiers for MicroPython?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2016 05:43 AM, Radomir Dopieralski wrote: > I'm not sure this is the right place to write to propose new trove > classifiers for PyPi -- if it's not, what would be the right place? If > this is it, then please read below. This is definitely the correct location: the former 'catalog-sig' list is retired. > The MicroPython project is quickly growing and becoming more mature, > and as that happens, the number of 3rd-party libraries for it grows. > Many of those libraries get uploaded to PyPi, as you can check by > searching for "micropython". MicroPython has even its own version of > "pip", called "upip", that can be used to install those libraries. > > However, there is as of yet no way to mark that a library is written > for that particular flavor of Python, as there are no trove > classifiers for it. I would like to propose adding a number of > classifiers to amend that situation: > > For the MicroPython itself: > > Programming Language :: Python :: Implementation :: MicroPython +1 for this one. > For the hardware it runs on: > > Operating System :: Baremetal Environment :: Microcontroller > Environment :: Microcontroller :: PyBoard Environment :: > Microcontroller :: ESP8266 Environment :: Microcontroller :: > Micro:bit Environment :: Microcontroller :: WiPy Environment :: > Microcontroller :: LoPy Environment :: Microcontroller :: OpenMV > > I'm not sure if the latter makes sense, but it would certainly be nice > to be able to indicate in a machine-parseable way on which platforms > the code works. Are there actual binary wheels being uploaded which compiled for specific boards? Or is it that the packages depend at runtime on board-specific features? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJYCNk3AAoJEPKpaDSJE9HYsl8P/2VBfoIqIE/NU4+zxfjV4pX5 nwnrnjxjfHEGIibmdhM0wh6CouaqqhaWdmgMKu66UoZVmJFiE/WAPYmHhcC0jHSC Mk699B5+fZATywJp/NweaogpcaJiEvJEpcostD4Z15sfmzYCrrOZ4ylDSPq1+D98 ypQRhRjxjrMu9RxIOOJFOKHbvyHZ+NThAgvF7e7sDG5SVWeEPVN9ga8+F9B6JJjw 0Wgo0G/pTrTikVr/HSAbpkiQZRey4rhaN6hg5y0C4O2M/Sf4zrik0BfC8eWt23HY tIT2EFhr5NR/9JaFYWkgZmrVFf23JJezS/1N6zGVKFIaf7AsCGh1LFy8jZNYuA7P 7uNzPM+9otgPp7Vx5w/rLKQXN2MlUKAZmX1FoUz5MBL3m7RaCctYMbxOaxxjXEJy vORr1r7iOm9kw9YXIuVrtI5X9d+518IQ3Ege4JxhIhi+V90j6ht1wAXoGdLCqYNJ OqrMbayhEatzj9dWu+3P5CrzyEfe2frahdBcms+PT/uDNKXA4SJBEibHYfv16yWb Z26mx3sD3R65ceRl7wCgYy4G3rt1DTro2/LGfm2f92HHdmIHNWJI5sPcJSst9n69 1AdLZU6N/PSS3k5LRLia4GnTVfBJBxphTfywIcP81kHNLUvBvnX5bQhLnYAGL4Yj l3sj1cK2n4dhWhvDLYds =nBUj -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecating PyPI as an OpenID Provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/2016 04:24 PM, Ian Cordasco wrote: > On Tue, Jun 7, 2016 at 2:59 PM, Donald Stufft > wrote: >> Longer term, Python should get a centralized Sign on across all it’s >> web properties, which could re-implement this feature for folks who >> want it. > > I agree. This is should be a goal for the PSF. This would help with > elections and a number of other things as well. I think there are a > few solutions like FreeIPA if anyone on this list is interested in > looking into helping the PSF implement this. IIRC, Christian Heimes works on FreeIPA in his day job for RedHat. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXVy+lAAoJEPKpaDSJE9HYIBcQAImzTHtAzENNR//GswKjxrCT zYxSQzdsQtBjpWOB279roeHfpZRSf6xhy9HjUhOWGIQ+nDgEcIgDUIU1BIg2ZPgJ zQcMcjV0wiOAeyeVdgRtKXw3o4UW4XijuS43C29s+rxHvGPLPziQGQLWk7SZdzjf YAi12Us96rj2m0uuXjpOPVZjrztI0ABdcA2yRJuDYiMtVONH/4TP86n6NHnUznO1 RCoPsfLTn7BbU1hMDOdrGKOED4QYNskiDAiB5qtL/uB8zDgKRLlIhxTHq9/d2T7D 0836zTvNwoo/TwBwfUFn1Op8CXydls7yGfpRq43NNqgBNwhWxzImpfVTxB+D8MHm NCd4tPvgSJdyov2loYqToCytH3d+ueKdL77PG9ag7GCuOcrTggbBLhG5aaNknOSo LN/yZgF+geuGp81WlHNwl3duo0JgapX/ilQg96IZSy19DzZa4/mihJu1SurGB53u Jj7bpz10wCBMK5NJqzFYJ/gcAEqPQ7E6jzFQps65Eqs3HQTb33xOryptpmc7kZSR fT/NJG+0ctwjdAbr7pZX0Jyg8G2hWEOsi+pfY/22Ejs4gxmNnMWqqVcLzBm7glB2 sDc4sm573WtDRM6+dkCyyjKZMYwvWSbsIlWiIo27pdHXOTx4fGKxiJgqt4cD1IhC DN02co6A9A+t5Meory24 =fMAO -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Accessing tests_require and setup_requires from the setup.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2016 09:58 AM, Daniel Holth wrote: > Here is how you can write setup_requires and test_requires to a file, > by adding a plugin to egg_info.writers in setuptools. FWIW, eggtestinfo is an 'egg_info.writers' plugin which dumps test-related metadata to a text file: https://pypi.python.org/pypi/eggtestinfo Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXUdRpAAoJEPKpaDSJE9HYQhsP/jrMq4q1BgCCMCaazvo9B4vX uS9uzHj+T2noHwMcluSQB9zdSvCufNbKSoXQ62MUkbPEKwa1TarKzm+XZci/tBba eOxwEPilHHRBF7no44ZTgo6kq27oOC9Z0em7F9awADxWmJ0mcgOksQTXjzczuP7h BPoj1v/vxSLc87Q61qXYWMFTpiY4SjHn7+0xu7txQ13GJSaNjqNK/geQI+18Tpw2 76G0I1TDbXel+2JlgYEmwHkFPpFuhVaJXyJi8ZjvjdH/jN47oT6wsFwyxRzlVOXx oFp//hdb05K9i2R9rdLznKzkrQCrlYUTEBXEIpMCacfnoHgKrn+MKHCdI4FXKXGz Rm8LUh+oS0VU5IA8Rt4od08Qd68HE9CQERvx03JOQ7mKJIjxEODeC80JduzVGZxj 7YpA5sRxbsDTbnHD+8uodpFDDU0h9NMWLbxdDJ42Q1j2iNNr7ZZDR2tJZ8Y76EMl 55Mf5WZK5W+kzkUVodpK1yTxLR8+swadfjno2QnVhjA9h3vW1ZV11AREPTLauHbE S+eoyN92ga4eyhZSwaQdhz6KsZgFpUcmhwvlrsl0dIlkkHs1mFjPL/J4PvR2SVKl ug1Wmm0EvwPUQ0cDcRBeJtPF4git5SeMYLvGcMbsIpHdZloK+xaFVyMjgrTGA1o5 NTZokg2p47XvwuCA4XlH =d2oJ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPi upload fails with TypeError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/2016 10:57 AM, Luís de Sousa via Distutils-SIG wrote: > File "/usr/lib/python3.4/distutils/command/upload.py", line 139, in > upload_file user_pass = (self.username + ":" + > self.password).encode('ascii') TypeError: Can't convert 'NoneType' > object to str implicitly > > I verified that Topic :: Scientific/Engineering :: GIS is a valid > topic. What else am I missing? The TypeError is about the *last* line in the traceback: One of `self.username' or 'self.password' is set to 'None'. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXPz6FAAoJEPKpaDSJE9HYV68P/jlp6buHOZeaGdEVcSiPV/V6 l1FCk56Wgu8/IOjIA/APLH5USMfABESt9YHKBzMENfRQpIbaMs0CmhdE5ONeJs3F LSOGEiY4i5QWNjOlw1oE5GaG9Hj31XuzmCMs39kIQ3C+gOXq/inGTIF4fsvGmK/l dMfVEWmbG0OJkcclrgrTAiJ79La0408ci+N62hsz4s3l+d0F9PUZXd6gpl6AOzMm ORr1IMsGHLfhyWFVfmWoJxyRUJVeGE+t3wY6CCOJEJEckbezOVXyxkBnkSxhVpwd fwffKpNTwFRXvggH4qPcDmmf4T6sAS/hOkBBw0WjcbNMRlFzCaU7Ehr2aw3+wxjU H8GAsn3Xh2H1T3c4qHUYWe7X78/mPN0Pri9Rykg9NVSJ9m1awq94tJgR7tH1om3U +4UvzzkyIKIr8a8YikqSjKnTrJWhqtnSJ+08D4zlBoA1R7lQMdD079wOnmtaLKYj ogYf9xG1jFpVWUeCOdh6qHlQikBHWFWRFSMootKg/tRd6qrsLsbaoaIlEGefPEtJ NgOQ1wMYWthzGglkiktGF7Fv6qHit0rYVSOOSu7gIxQbpkgOylaIwGDuvkArELk3 WD1AJ/F2gc409/IhrvJITP5rP+sdJVMtJswEqYvB6zxaUURvt+Qf4crzqPUCvrAp aKxqMdnFeKZ5jqKRrXge =Ov3n -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2016 04:36 PM, Ronny Pfannschmidt wrote: > its not given lightly, and it shouldn't be easy to weasel out of it. > Actually a noop release is a good indicator that the mark is > well-deserved and should be keept. Making an effort to remove a mark > without making the reason for its existence go as well is a lie in > plain sight. A release, any release, is a sign that the maintainer is around and cares about the package enough to act. That should be sufficient to block any takeover attempt. > this reminds me of the whole setuptools/distribute situation. I don't think that means what you think it does: the situation was resolved amicably, via negotiation with the owner of the original name. The fact that it took longer than some wanted was *not* an indication that it was the wrong outcome. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXGAaCAAoJEPKpaDSJE9HY3FIQAL87jOyqytF1MuC5SHqiw0y1 p7BYWrLf8MVl+DFRJ0x0s9NPVgvkeF+rbx17WD7k8Eik5iuXzTpjIun0oI9UBkwC iTpogEwDrFg3T/s3bM0ObAphcLFHAY4YFMXsUThODtCHg4qi/04Z9RiMhnabwitP GfzuI33aDZbgkyi3ozEse5rP1xTn3SmhtHwu7k5gQvAmg8ntpXFzP7l1IXNWtPr+ SGXzsgohZwsDdOBwOibbvQ3VQSmeLBPrfsP0xVzNOIh7GEHT6AXMM8qK52Er4vMd SQmR2r0WAShqDm+LadfK/KjrvwSgQILpp1z4jvY6k3PWhtLABEeotDZj5mgRY8Hf 0+NTBuifYo7SHs+ElI4nryDbp48q2DZH2PLdh3WgyMlLzTocXTjQcwOTEZGcbb7t s5u+/cQLzfvg4Z23i7wPGrUrBZvl4YM3YKZfsC3Pl5v9jfwiJm/ay7G7O2NHstdB inI23H427ELXgPLI8Ffi9u7MQ6zTCd0H/XNxaiWAhG4JmMZyFuNqJQAuZ9+cR9N+ WWPEpfpHhWW9pYdxKWPHJLWKoGTu+6qPqIMnCPn3sY8ACnqH7z5puNu+/uAJ3hBt PNVh+wKE4R1wNXHKHaHqVqMH/Ut057hEh3EIOwX5e8W/zCojZy8O6PjmaFW7EGdd BMtyIkp2jgQJMY3ClfP6 =w60N -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to deprecate a python package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2016 04:17 PM, Alex Grönholm wrote: > I think an ideal solution would be to add a feature to Warehouse that > would "redirect" any downloads of a library to another. Though I'm not > saying it would be simple. Such a feature would be doing a huge disservice: repeatability *matters* for package consumers. Unless an already-uploaded package is known to contain malware, or the author is under force majeur compulsion (governmental / legal injunction), removing a distribution is much worse than giving the humans involved flexibility to deal with an issue. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXBDaKAAoJEPKpaDSJE9HYGYsP/AtJGhNFXPXjtUlTVoDHw6oz ohzb5js31Dps86V/CQELl4cxFhfPMpPCPxcfA9z/E9B4Wk3HaFTPxOUunZKrbUJA 2MguOnsYOjeWCBSlBEOdjCSTHiYse07NRMV4NN+b0mfdnj6VvTk17uY9UW96GTiN xigRgysRgN71JnE41ZNL+4qKjvCL/6dYFrga21rdvOGnZrTNUBwP8mbbACrdz9lh jeOSVkbWMqKazAXIZB3y7KaByIHIfes5fguBnsjqpgdL9c9r8WsE5nhBCdlkUm8N NAiNEpTy+5G5o0NhGz/4AXFtamkVLTGSZhWcUprHOtJUgjzer+b0WWijFcBtcQGY Ugbijhotlbx+zI/QPqArqDemU++UhGr+oiI839KfyzV3viZ4MEr8jC/BchM88Jmn 8lR3Fyv25Tc2bDTC96hv8A5zcwM08i5FYHlPhW2a96xue5Vl9wZ6rmpRUTtqhErJ vwPu/Yps/l1nXzRXPc8NcHTH8daDVIgaNNp8EeDHV+vYJgy066zzzSQ4dTJddWbZ mcf6aFQDP50vrloZ81GaeByUJ1xlcVfyODdvpKj350YlqPqyv7y7uMJv026csRax l/3DyhChbqzU/be9f6xaGL+KzJU3Xt2L0XY/annNkBWrsbRKISpiiGc+21rNo23P EB9Sax3Uoa47h5GWQWH5 =CblP -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] SOABI for Unicode ABI on 2.x (was: wheel 0.27.0 released)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2016 05:35 AM, Marius Gedminas wrote: > And people who run build Python 2.7 with './configure && make && make > install' > > Why does upstream Python default to UCS-2 builds on Linux anyway? I don't recall if it had any bearing on the choice of default, but Long-running processes with large quantities of mostly-8-bit-compatible text strings in RAM (Zope, nearly any other Eurocentric webapp) need measurably less memory with UCS-2. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWt84xAAoJEPKpaDSJE9HY4KwP/jTTsxXJssYd/aPXkY3MSObU BI4BpBvgHcQnyCGJ7gUqjS7MtHcHb0iz1ch3xAZy+lz/kXhB5+Kd6q9mad5altAa RK9RK8+i4UcS4Mwd5KMKfXuaOygr/AyrZJ4C6vgNFgN1HKD3HhLtgJAwzeyk1HE+ 5ZN2XEVUVhYeTUXdP+qCea3SuPf2O0zADBat/ys8JQ0MMKPscm5acKE5uum3w1eJ 2nrF/8EP+LgZFw/3WNQON8tWKz9Iqwmqr4022jorOi6yq0OG/MAPzjNuSDZ6Ab9t klyDVbVVuFVdiPVhMd9viaoYJ5Q2DoFJG0jnt58B8L5N7M0wn4UTT/ZX5vvZJNoJ GqoavyWiFbLEu3+btlInkTioGYhNtwZKZnTH63Gjri2LAk5C4SmeD0vYiJMrHaCA ySGTLwmv/SiTNvKI0kVQ0DcJ3WP4mHherq0bB6UeNEcD1MVuvTfjM8MSelrmo4VC eJsvKfMcpZ0l3V5fX00AbE1TWTrz1DDojVzR2KH+uhUjzegZt0B68StOg3drxh94 f37Fs7CfenVsCGyThguZX/uZAtQulCDe/UNx/86cX+GuMNA5qifu8IIYb7UM/fIX Itn3fjYpjC5fhRFLiUKR3yuv9h1eckgefRYINGzB2d3bZRnkT0IsurSbg6uvt+UE ixNkskENFDuIQthyvCbQ =u3iS -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Reviving PEP 470 - Removing External Hosting support on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2015 07:51 AM, Donald Stufft wrote: > This leaves the user feeling annoyed that we didn’t just search those > locations by default. I truly think it is a bad experience and I only > ever added it because I wanted the discussion to be over with and I > was trying to placate people by giving them a bad feature I don't understand the sensibility here: an error message which tells me "not hosted on PyPI, try 'pip...' instead" seems like a *good* UX to me: Having a tool which respectw its default policy ("trust only PyPI") while giving me the information I need to off-road when needed is a good balance. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJV3x+AAAoJEPKpaDSJE9HYE+IP/0LiQ+TwRnDvAcDsRG9wXPWd l0D2jnw6uGkJez5CJD+4JA9x3SRabixY+K1VRffgnG8NuR0omfioJbAFXyQVV9g1 ymUEZzJG5O8kd7v+iIvrguu/dGu1hAH9nwsLQwAkPdrUSfB6YFIfBmJfpb3vqJAx Frf6A2zAedwLGTB23XFajJBYpDXZGjwj1+N6zedDHvC0xfN+fRW3jyYwaTJYklDU y7HZRuSIOuy6mRgjwi73iNsSexY+jcIyKWdh4msD6+BLge8X1/8BuDtA5Q5agMrH ZxrlHaVv5AxtDks6lYzIhSocK2D28NiU2IBbha8OC9NUnmJdNHVHmvmR4UNTjYTY cP1+bi3cMQ28LVcuGffXoV4HlydpOf1QKIOaK6fwecr6ooIv2Y0/BJrSElgCrBZ6 tx3nP/uHd6R5GoxLl88ZyT7oFsoPQUVSsWZTc+1hnxI7PskvTAZXogUJShO0um+9 hKXjmc911fGKMszNk8xnagUMWJVimuBwLZwsVAjg9s0D5Xfq/LRS3qzs88Dwmb5C FPpaJINqgSfWRkiivgIsO421PUuX+vyjLr13vcfCaN5TCwHQujgOe+6PFqOjjVNC UONyy98A3RzdUuBuRruwzFUkaBRjqra7TMQrFzhHFIwOeiY/T2dMTRnMfAlC+TVO hv5zjuS8U9/WqpiWH2zq =a10G -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Working toward Linux wheel support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2015 11:46 AM, Antoine Pitrou wrote: > Due to the fact Linux binary wheels don't exist, conda is even more > useful on Linux... FWIW, they exist, they just can't be published to PyPI. Private indexes (where binary compatibility is a known quantity) work fine with them. Because it nails down binary non-Python dependencies, conda (and similar tools) do fit the bill for public distribution of Python projects which have such build-time deps. Even given the "over-specified" platform tags Nick suggests, linux wheels won't fully work, because the build-time depes won't be satisfiable *by pip*: the burden will be on each project to attempt a build and then spit out an error message trying to indicate the missing system package. Is-that-'-dev'-or-'-devel'-I-need?'ly, Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVrbuhAAoJEPKpaDSJE9HY0R8P/jLBINO04/NTlJTUa8wmIxed aWSU0mxFSAKg0q+n2QaRi418QG6vvtUVGsXGafmYu4hlfKj3Hkj6DA+ws2o7uR5S 1UNU3KSF2lsLoWjaIKpMm4RNWmbHuWQ3HlabXqSly7H7lfgXCAzntdrVy5s3zacM 4wqVTjTWaG2lBf77B6aWhgom6kTvfnpNtyQ4+oKDujSnSWlLJ1W7p0hvuR/33XHr 1NHUdaoUWH7kES0zcRHOyYU7PSPtVYMpzn3SKWljMXSiN1vs9YN6WmypNmLeXjTj gkD/JR8gGv97o9TliKW6KaocbSLvZ5w2bHwkBGYsLRS2pti2ojw+3vmSpm4VwKyn PLhOaMpBR4qC2scFVJ5z1iW9uOYlakra45o60rAaRTiuKEHBPaoimQP3mMW38AsB glY+/j349A2XyE1vosAekxeuinip64erQg6G3+gU0myRsfaaC1lTBlzkDrsya4X5 C2LbE4n2IlMrm+hrA/RbUjKlbTJtIyWLlnrv1jORh6l5VNTXSkafStA7j1nXa/hx 4zAqv9mV/1UErI+IjPz6CQTwNbz5QtSP1gFa/9xqGnnrBSuWRMYd/x0c+JNXFzFC MCMhbQ/ZIAkpmk/VRb1mVQVc2uqsWr9WxZ5F13cJJvZrvWkQJFf70nnHk+n2f3CU 9/s6HEGX8SkP8tZnZ7Co =gpd9 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2015 07:10 AM, Antoine Pitrou wrote: > Seriously, how this is even supposed to be relevant? The whole point > is to produce best-effort packages that work on still-supported > mainstream distros, not any arbitrary "Linux" setup. I'm arguing that allowing PyPI uploads of binary wheels for Linux will be actively harmful. The chance that hundreds of project maintainers can get the dance you are suggesting right is iffectively nil: it requires them to compile wheel only on some unspecified LCD platform which most of them will have no access to. Once uploaded, mis-built wheels will cause no end of pain for the hapless users who try to use them. conda *is* the right solution for distributing cross-platform binaries for the relatively small in number (but not importance) hard-to-build packages. > Instead of lecturing people about what is in your opinion > "intractable", how about you just shut up, if you don't have anything > constructive to contribute? Really? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVnVhpAAoJEPKpaDSJE9HYnxIP/0b9dCEHarpzzzZP+fam04i2 a1sdxLn5RodGcUF9kid4KsdtOMc3D1sKf0yLbuBA7z1ctMYsPDYPcmvlo4cW2iSJ WHYaBm1nJ1JUIxBDagWl5IhIO+aMtRmBQ+UnRj2vQi6Clga/d0M0T1+lNhAJy4hs SogpFx3SayW+BotThqY1JGvAaKyM5hGYARAQIlrxWk2Ei6pff4mNAdXd3t1hjqg0 Y6PlBVCo9APFtbtO2AyzdVY5Mp4D6QqDcdj3NhjHsukvPTlpgv1dk+jJgPJfTxCw Gx0Gv2Zt673y9QNOer6Lp3A/jkLG6w5mnY9K3lid+wx3Pv4wd3NNy+O2FuopKHZc RdE1mWVe5W4ufSJVhdaXTOj5Eww9KnL5SH3KbTYBbDST7c9pFM0tnk/8Lq+4OU0z soGCrZtH5mjof7LPDkvVh/j/mrLeRo+Wz9JsaAb8+PZVDuBSEfHKDxoKcmO0VzAx weJE24eNfqCLzbQKhaIiXWA21D2jE1KxdUuzf0qJwwlkPaa4BmvMzJ0iKMeZYFf4 lYnBhNBJhZSGDTPpXRiM3Q73bzxvz3OYY/+6lcZU+LYx8LIHmQMrgHDddh2E9FvQ BC4sfIBGt+LTbZPSsK0xp+MbX1yoW4TcXZeA/fe8/e2GY0UFgKQRD44Fa0hRdU7b QXabMbyCHLKEKxc+xmXF =Lrn9 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 07:43 PM, Antoine Pitrou wrote: > That's a dramatically uninformed statement, to put it politely... > Some packages have difficult-to-meet build dependencies, and can also > take a long time to do so. In the general case, it is *exactly* those projects which are going to trip people up when you upload their binary wheels to PyPI: there will be no way to know that the compiled-in stuff will work on "any" Linux, and solving the problem of "which" Linux variants a given wheel can support is intractable. At least for performance-snesitev codes, building on an old, "least-common-denominator" platform has been unsat: squeezing out the most peformance on a newer machine requires compiling on exactly that platform, using the best compiler available for it (and maybe tweak options differently than are even possible on the LCD platform). > llvmlite, the package I'm talking about, builds against the > development libraries for LLVM 3.6 (a non-trivial download and > install, assuming you can find binaries of that LLVM version for your > OS version otherwise, count ~20 minutes to compile it with a > modern quad-core CPU). We regularly have bug reports from people > failing to compile the package on Linux (and OS X), which is why we > are considering the option of pre-built binary wheels (in addition to > the conda packages we already provide, and which some people are > reluctant to use). A conda pacakge solves the problem by pinning all the underlying non-Python dependencies to "known-good" versions, which makes it the right choice for folks who cannot / won't build it themselves. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVnO/AAAoJEPKpaDSJE9HY01kQAJV3Jht+KBdBfWn9w5G+/bD9 /8XRweaHFl+jBhFc+NEKjZg1Nfcz+bF8PHvC/unsUF4hBMJyeMtAadutDYVvlbOb hjUnY7BF94ssP1HcNJW9x7eQfKiwQqdOxr+4r15YkYGf0osW/JJ3SXYj/R9GwQ1c d/ZlTFtbL+fZaEEwUHS8pr3J2hx9HELFPQI3VCdt7AomNqGMoM92UDPXcyOvLUTB OfswrojVM2g1NJclvVEbd0FXIO/ScQeDYVd767LIynMbv4xQoB8/Bs9B1RBEj+gj ZphfRFtGssEHiNKN0Txk9Z22aYqQhlmxiJJx4mqT5qaSyY15iG34WsBh3gwqaDvR o2VaWMDAtxunqqiB2E1NXGzPH5InivalG1laPxYs2SZJMsYn0M3y0FDgNaV0vHuO JC3U1ckVm/oeuLhmaHmi/qzfaFTAxo4JPPcTxYnAdhVWqmWOQJRz/q20acpUu7Cx ZrezhYOVeDkF5AB+XyU6O4e7a0zB7r9jKKSIn/6EJHrMQ+l744U3nT+mJ31CIIO2 ZAYAm/ZOQK8MtSBAi9rVLzKmkyOAnUX/Fnil6uBYHAeBiIRy+BLExuzcT/0bNBXi Gfhzky8/rw7RCdBUTHeWY1y+2cZpq3BzFDSZqXMPT79SA3I+kQ9wAyyRI0x5tB6s 0ujHYOv331tJooipuYrY =JH2E -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 02:18 PM, Antoine Pitrou wrote: > On Mon, 6 Jul 2015 19:03:19 +0100 Paul Moore > wrote: >> On 6 July 2015 at 17:24, Antoine Pitrou >> wrote: >>> (yes, the version number is off - but that's besides the point >>> here, I think): >>> >>> $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl >>> /home/antoine/.local/lib/python3.4/site-packages/pkginfo/installed.py:53: >>> UserWarning: No PKG-INFO found for package: pkginfo >>> warnings.warn('No PKG-INFO found for package: %s' % >>> self.package_name) Uploading distributions to >>> https://pypi.python.org/pypi Uploading >>> llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl HTTPError: 400 Client >>> Error: Binary wheel for an unsupported platform >> >> PyPI does not support uploading binary wheels for Linux. This is a >> deliberate restriction because the tags supported by the wheel spec >> are not fine enough grained to specify compatibility between the >> myriad of Linux variations. The intention is that once a resolution >> to that problem is found, this restriction will be lifted. > > What if packagers take care of working around the issue? (for example > by building on a suitably old Linux platform, as we already do for > Conda packages) Compared to Windows, and even somewhat OS/X, the win for uploading wheels to PyPI is miniscule: pretty much everybody developing on Linux has or can get the toolchain required to build a wheel from an sdist, and can share those built wheels across the hosts she knows to be compatible. A-foolish-consistency'ly, Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVnGGVAAoJEPKpaDSJE9HY5McP/0MCer5wS0MygSHw/UGrcvKN 2pDfGdFsucjY2cR5Wr/R28NEvTPzrmBghPAw4x47rNRpNWBOHvRMyOu3UWKJIeMI r/elBcP9te26jA7o/clqkfnVNKGjcoDSis+YkyhZAfhEDNGXQAaSf8uNFsVDKMTj W8ggxe0DraXHImE0X4rahu2a7Svd7yWIMtRv5eMP+HjfLA9ouQUuFNYXCuXDmTIS 5SJ+XkXjToKy0DSqPkknESVcCnF6sDjI1STo4dPi65QNlUQomv9m3TwLN9Ak+bx6 u0vM8R594PXMcb8cTnBXdmDbdDhQRym7Wy2Fr5zYs7nwJ8x13d2QKs5fQ/QhmUF5 DtyWeQekhK1+wupt6NQ8tXgu9jx9SV81XtvZSAp9SAVS9asC7BUjLAZEh9r3K07b dTkaY719vFUioiYQazDjIrkMLxSKjGbBgkve78tkjDtfwvKDOBqofFEmcsBv8yh0 wA5/iYJ78Wmr2rti5d4/JwLU5Tc+NkkYcw1W0bRUgi+GX8vYtYQ03i36f33Kyf3f z6n8rquZhGDIcPjbrEmveBJxErJTu/3ifuIy6NnTwCFmQNOl+HpqtJFtYS1a3NUR 0s9eivFgl6vwExN2KywYW9N/6tCcWyB0qvECG6tB/a+Ao3iW8KOciyyjaQZWwOFx glybBbAdFgtqaLafaJnQ =NgK8 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 'virtualenv -p jython' leaves 'pip' non-executable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/2015 03:43 AM, Suresh V. wrote: > Could it be your umask? Just wondering... > Nope. This issue only affects the 'jython' environment -- all other tox environments run fine. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVcECOAAoJEPKpaDSJE9HY73cP/ip5pY1NxhdOo0jAHACQxGGN U4bhzcNm0Qy+WGHQfCfNnIVAVMNgAdFV1nfI1Uu6x4I4lS6Ljm5Q1lXn4k4SqHcg ttGs1nDDuZYEYFooKKxOsLOWISwR7FTQct9tOUAZa+uu/a1uN8RyjwbB2/c6XOJU HR0FYfIAn37yZ3I6pITFrC5cUJ3E2ddDZBjim7jHvWGgQaSb+5fjor1BRKzrVj46 L6nxLPLsaQeepJtWGvDr9OzIr4zfovhtSdLXOr7uCNrORk49VGQYETjk4hDenB2I c/OFEFt+XTL5Rf95fTQNj7v04rd80witBTSN5xNEyIqYaduFinbql2gEmTkooqpc cJCkBHpphHY5UJj9fnQPqVKQjRL0kaopWXg+4DGEqPu5Rj+V21Cn9BHad8flo4No jjcwSFjRTqJdfc4uzQ20UMZFOkX01Ak/REO77MfxcywE8nqrRFqC8j8IS6gGKWAN +k7/UjgoOzC0qzmjnYBGBXZH/UgQMPFEcIQ2HJ/o1G7vL9y6MocC2Hjc558YLfT6 +IiDmOrIErxV8oMWkarCoTFdW7aILim8AbCQ/XfUezVE3dNkbXuXf/VoUWrOutni CMwpDTcwdZCvdqnwuE2/nEZcCQUTxyaVUorSERjsDGB3SWuInbYniepNqAPFQr0y yaCBn3tBhnKGMIwmRku3 =GYVu -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 'virtualenv -p jython' leaves 'pip' non-executable
w-r-- 1 tseaver tseaver 211 Jun 3 13:46 pip2 - -rw-rw-r-- 1 tseaver tseaver 211 Jun 3 13:46 pip2.7 lrwxrwxrwx 1 tseaver tseaver 6 Jun 3 13:45 python -> jython* lrwxrwxrwx 1 tseaver tseaver 6 Jun 3 13:45 python2 -> jython* lrwxrwxrwx 1 tseaver tseaver 6 Jun 3 13:45 python2.7 -> jython* - -rw-rw-r-- 1 tseaver tseaver 218 Jun 3 13:46 wheel - %< None of the scripts are being marked as executable. I don't know whether this is a virtualenv issue, a jython issue, or a setuptools issue. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVbz80AAoJEPKpaDSJE9HYg2EP/2sWlshPGokrrhOZYV/8YgcM IFNa2JlwKNwPefKtQ7VThrIqYHCTo8UuLC+6mv1JFvXIT50dTubOFeLP2ddR9X1f Ma5kqwlCs+lf1VhqWbA5BIkg+p3GH+l/CImudJOijxF2Lvlx1sHvIOTZwgU1qYvG cpMAOW5D9rT34oU7SEf6mIGro8cGVa3nEMsp8optU7iOZTzvgQG1nyYknfBJquca jwjwBOgrxaZkIaYrCyFWspR8sdPaWs+9S4qR7RsXkCWYHbfjtNKObJB4CPw4VdIV S0M16pz+znrY3nBggrCFzLAyJQje2E5mwNF1BDMKCrWTbUbdLmpbWMdV0//A68kP yricqNoH5Juw5PVCl5AiP49mIAvBUWipyD57kUVNP4ndlU23DMiC7/ClqS66HSw/ HCiThu50wVwZ4SYX/YOGmPorQKtmntLbLhGx2Oj1f74YoqVtcrTUbqeFG0MIW2W5 EU8IHy3k9n8hVacP9bm0zipUAX5/AJe+vS8eA+14B9pbU690hLK4pQZ8EYM2Dn87 mT7ii9IKgXUElybMWqR5v1w3kwbj/lRZbFqJ59x2cE0Kar1z5P95Eij6GgRP5sBw 6EdtK/35HVOk5K51Wkd7AWfVawSYRV9NoPxFFNcj3l5MqyQI0ewt85KpuYdeHYv3 w/9dWcP6PNXmDxA2VXA6 =eZat -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Released: pip 7.0 and virtualenv 13.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/2015 12:21 AM, Donald Stufft wrote: > I'm happy to say that I've just cut the releases of pip 7.0 and > virtualenv 13.0 and I have uploaded them to PyPI. For the full list of > changes go visit the respective changelogs, however the biggest change > here is that in pip 7.0 when pip finds and downloads a sdist, instead > of installing that sdist directly it will instead build a wheel of > that and cache it locally. From then on out it will use that cached > wheel to install instead of downloading and building the sdist each > time. This can have a profound impact upon installation speed. Nice! I was hoping that this release would make ;tox -e jython` finally work: it's closer, but fails now due to the fact that the '.tox/jython/bin/pip' script isn't set to executable. I don't know whether that is an issue with the pip bundled in Jython 2.7.0, or some other weirdness. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVXxoyAAoJEPKpaDSJE9HYhjUP/RADiv/qM2xRg8UednYfxLub 1AUQk+GRYR4B1zbcNu/f8tcXeKePde7QaQ3si1EE123CBQxk85xqMH/2oYFqwCsw Dxb7QuQdHhhuImxpM4SIVJmb0Tm8YqYIkDNH0NAuRVWkgaWQDfQgHVYlNQWxog/e 8hEnEWs3HjF+9+7GcTL7ny+l6CAmlh32zJaPQi0j+hzYbS54iShYzcWzlkSltFmU N4LLIlel9SWyX0WclpeuP4hhygpPlkqAoMPmh73m1/74jk0My8qXC2UY5KwU/Iar ugK3KOTAohpeTvbgK9wdIzOuqYoX6k0IgAHFejcbXWYoDNFUvS7HAqCoyCHA7JJJ 9SZsWRf8rCfaGEzWrAR3PVOMGmpLO4DuQBZZ3sypIRC2stTOtXzQc5gg0CjvHZjH DVmjXF0/WBcngAnUdkDjIwZTxvQuR0NJEV7H6ODMNwO+UaBGTCojih1JDVG+GYW6 2uXUSAWBlX50zBph6U2GbouAwUbtzTlb8LWFdj/GIQ2UvNwoF4f84EougriXFAnl ODkPxjHt0l9N8WIGfq2v32aHl+VsNgRMptZMV38fGxCSOGM6Eo/eUQgY2Qfcx8g7 wOUHcQRyTAs8AT0Dy++eOZNrdndvQFiYKUMIUzJJaeHuEbGaeKruiOva7/+65GNr N90Y/+cw/feYl/eIOeP4 =Me4+ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Module from install breaks subsequent install of different distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2015 04:57 PM, Ben Finney wrote: > My current position would be: that's a bug in Setuptools, it should > not be applying entry points defined for package FOO when running the > setup for some other package BAR. > > Is that right? Should I report a bug against Setuptools for this > behaviour? Notabug. setuptools itself is extensible by means of entry points. Both entry points in your example (as cited by Marius) demonstrate that: one adds support for a new keyword argument to 'setup()'[1], and the other defines a new "writer" for 'egg-info'[2]. By design, both of those are supposed to be loaded / available for any invocation of 'setup()' in a Python where the are installed (not merely for packages which "mention" them). [1] https://pythonhosted.org/setuptools/setuptools.html#adding-setup-arguments [2] https://pythonhosted.org/setuptools/setuptools.html#adding-new-egg-info-files Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlS9jXEACgkQ+gerLs4ltQ6L8gCghmv+gf1jTuesgd7+LU9iERbN ofIAn3KEQjxt5Zmcxrr1oi3RpW8dB1ci =59fE -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Role of setuptools and eggs in "modern" distributing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2015 07:20 PM, Chris Barker wrote: > OK -- I just found the --no-deps option. So I can do what I want, but > still, I don't think it belongs there and all, and certainly would be > better to have the default be no-deps. Let pip (or conda, or...) > handle that. Unlike pip (which provides no API), setuptools is a library, used by e.g. zc.buildout. The behavior which you find objectionable (installing dependencies needed to satisfy 'install_requires') is a core part of what setuptools *does* -- ripping it out (or even changing the default) would break nearly every other user of setuptools in the world. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlSupRIACgkQ+gerLs4ltQ5/fgCfZTk7b9+eVwLqJcztO1RggQJ2 XxkAoM0gYO+vV/sOrIcVqPFbCRVmAi+o =gRN+ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bilingual namespace package conundrum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2015 04:57 PM, Donald Stufft wrote: > I’m pretty sure the problem with setup.py develop and setup.py install > is because they are installed as eggs more or less and setuptools > probably doesn’t support it. pip install installs it > unpacked so it’ll rely on built in importing. I'm puzzled by that notion: 'setup.py develop' and 'setup.py install' have worked for a decade with namespace packages, as long as the __init__ for them does the Right Thing (using either pkg_resources or pkgutil). What has never worked properly is mixing pip installation of namespace packages with easy_install installation of packages in the same namespace: pip's "install in one directory without fixups" stragedy screws up the __path__ for the namespace packages installed elsewhere. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlSl/kEACgkQ+gerLs4ltQ4aYQCcDImoKfLr3Xb+tkFSY9x8Oinh QT8AoNDKmxVoqdX3UMnsUg1ktZbqukZg =CPP5 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bilingual namespace package conundrum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2015 02:19 PM, Barry Warsaw wrote: > Maybe the sys.hexversion guards should be removed so that it acts the > same way in both Python 2 and Python 3. That sounds right to me. I never really understood the motivation for PEP 420, but if the presence of that file disables it, then it should ensure the "old" behavior regardless. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlSlq/oACgkQ+gerLs4ltQ5hjgCeKMfXT0DPBS//0y/XAP2npJRW KssAniyBjuuhjVpw0ETola6v6hVuwpiP =BLOQ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Can zc.buildout use same comparison operator for versions as setup.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/25/2014 10:21 PM, William Zhang wrote: > Hello Can zc.buildout use same comparison operator for versions as > setup.py? > > *buildout* It use "show-picked-versions" for print verison > https://pypi.python.org/pypi/zc.buildout/2.3.1#easier-reporting-and-managing-of-versions-new-in-buildout-2-0 > > [versions] buildout-versions = 1.2 setuptools = 0.6c11 zc.buildout = > 1.5.0 > > *setup.py* It use install_requires for handle package's version > https://docs.python.org/2/distutils/setupscript.html#relationships-between-distributions-and-packages > > install_requires=[ 'django == 1.4', 'South == 0.7.5', ] > > Is there any way for "show-picked-versions" print version be used by > setup.py install_requires? zc.buildout uses a configparser/ConfigParser-based config file, which mandates the single equal sign. It also doesn't support ranges or other (new) PEP 440 syntax for versions ('~=', etc.). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlSd37wACgkQ+gerLs4ltQ7x7gCePOrTgsoB6fn3kVw7Vlto4t9e WtMAoKUCK4IVnNjZBaaPhvy7u6C3nIfD =26gz -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2014 11:10 AM, Antoine Pitrou wrote: > For me practicality means being able to build a single binary package > for all recent Linux distros in a best effort approach. I can't imagine finding any such binary useful (assuming a none-pure-Python project): the chance that it *might* blow up makes it easier just to create my own from the sdist. Such binaries would tend to bitrot, even if they were OK for the "supported" set of distros at the time they were made. How can such wheels be feasible, when cross-distro RPMs / .debs are clearly not (in the general sense)? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlR6BMUACgkQ+gerLs4ltQ70sgCeJ8BmRVDOhEzJ4I70eGWQCLn4 l0cAoJwoHcC26M/t5mhLXgJl4IrugDcV =G5zd -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] some questions about PEP470
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/14/2014 09:15 PM, Donald Stufft wrote: > On Oct 14, 2014, at 8:50 PM, Stefan Krah > wrote: > >>> Donald Stufft stufft.io> writes: >>> >>>>> If you're this upset over someone redistributing your work, >>>>> then maybe Open Source Software is the wrong hobby for you. >>> >>> Usually one does not tell a core developer that his contributions >>> are "a hobby". I have contributed 4+ lines of original, dense >>> C code, backed by 100% code coverage and 3+ lines of ACL2 >>> proofs. > Uhh, maybe you’re misunderstanding the word hobby, unless you’re > getting paid for your OSS work you’re not doing it professionally. A > hobby isn’t a negative thing, until last December my OSS work was > entirely a hobby too, and it’s still a hobby in my spare time too. That use of "hobby" vs. "professional" is completely irrelevant to the discussion, and is effectively condescending and ad hominem. In my experience, the quality and committment of a developer's open source work are often unrelated to whether she gets paid directly by an employer to do it. Getting paid *does* make it possible to devote more time, rather than passion, to one's projects. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlRAPOIACgkQ+gerLs4ltQ5vWACfRDCmT5yjkqfeBB+4xGAiBnAv n7MAoKag+7GkicRdZ9eSpJdz+HKml6aG =5Uxr -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Enterprise Python - Multicomponent Projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2014 12:57 PM, Jim Fulton wrote: > On Wed, Apr 16, 2014 at 12:18 PM, Tin Tvrtković > wrote: >> Hello packaging community, >> >> I'm investigating ways of setting up Python projects at my >> workplace. We're predominantly a Java shop, but we might be dipping >> our toes in Python waters (finally!) due to a fortuitous project and >> my multi-year insistence, so I'm contemplating how to set up our >> Python build system to minimize workflow differences for other >> developers (well, and myself). >> >> I've actually written uš a lengthy description of Maven and why we >> use it but I'll spare you for now. :) To keep the story short, I'm >> interested in options for setting up a multi-module Python project. >> By 'multi-module' I don't mean a single setuptools-based project >> with several .py files inside, but a way of triggering a complex >> build process with a single command that would build all sub-modules >> (essentially sub-projects) and produce a number of end artifacts - >> just like Maven. Imagine a repository containing 30 separate Django >> apps, packaged independently, 10 utility libraries, 10 Django >> projects combining those app, and 10 RPM building projects for >> packaging it all up for deployment. >> >> As far as I know, just using setuptools isn't adequate for a >> workflow like this - setuptools deals with the build process >> (testing, packaging, etc) of a single project only. Solutions that >> come to mind are: a hierarchy of Makefiles, shell scripts, or maybe >> Twitter's Pants, which sort of looks like Maven for Python but would >> probably need contributions to do what we want, and looks >> predisposed to building PEX files which, while very interesting, I'm >> not looking to do right now. None of these solutions are really >> ideal, especially if I want to support development on Windows (which >> I absolutely want). >> >> I've even thought about actually using Maven, but that's just a >> Pandora's box of problems waiting to happen. >> >> I'd appreciate insight on this from anyone who's thought about (and >> maybe solved) problems like this. I'm also willing to engage and >> contribute to improving the situation, especially if there's low >> hanging fruit to be picked. How do other companies handle large >> Python repositories with a lot of subcomponents? > > Checkout Buildout, http://www.buildout.org > > It addresses a lot of the same problems. Of course, for Python, > compiling is (mostly) not all that important. For us (Zope > Corporation) buildout is more about assembly/deployment, both for > development and production, that building. buildout also allow for reproducible builds of things that *do* require compilation (e.g., via the 'zc.reciple.cmmi' recipe for 'configure-make-make install' software). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNOwLcACgkQ+gerLs4ltQ46aACgts47yE/ErKtqag0FyOEpfCZP 4pAAoI8d04UodGt3NQB0AzPPJbJITPb/ =vBpI -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Pycon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 03:06 PM, Daniel Holth wrote: > Who is going to pycon? I will be there. I'll be there Tuesday evening through Saturday morning. I'd love to buy any fellowship^wPyPA members a beverage-of-choice. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM10h8ACgkQ+gerLs4ltQ48ewCgsyGo69m2iKAHAUtiC0/43G01 iTgAoKfZAWphPIoQj5Iih/qIJ3Z8hTqR =ETBo -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2014 01:18 PM, Vinay Sajip wrote: >> Does anyone have any thoughts? > > Note that there is one situation where scripts for multiple Python > versions reside in the same directory: per-user site-packages (PEP > 370). If you install a package which has scripts and you don't write > versioned scripts, a second installation of that package (with a > different Python version) will cause the first script to be > overwritten. Much of the time this won't matter, but there might be > scenarios where it does. > > It may also give a problem when uninstalling, or when verifying the > installation (as the hash of an overwritten script may not match > what's expected, as per the original installation). > > To avoid overwriting, one would need to write versioned scripts > *only* :-) Heh, sounds like a call for Underdog^W: $ python setup.py altinstall Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1vkAACgkQ+gerLs4ltQ5CLACgodRwkXiS9irK/nP3dKPnlaXO 5GYAoKbJ4NiDFJdHNIWPozIpMzN6+z62 =q7Bh -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] waf can be used to compile Python extension modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2014 02:37 PM, Paul Moore wrote: > Again, though, that's only needed for "pip wheel" or for the > install-direct-from-source cases that may not even be expected to > work in the new metabuild system... Hmm, that is a clear case of baby-with-the-bathwater if I ever saw one. Installing from an sdist has got to be orders-of-magnitude more common than anything requiring a separate compilation / build step. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMsieIACgkQ+gerLs4ltQ4cTACfbzcmVCMkAcXw8/4IWmNonAZV hlYAn2iNppd+ICEz7L2qr4sxnIISqykY =Dzaq -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Hello Greg/Anthony
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2014 10:51 PM, Matt Goodman wrote: > I have a couple tweaks which makes distutils more functional for the > mscv family. Namely exposing the compiler/link flags that are > necessary for linking against Python without dependence on the full > msvc import being successful. There are a bunch of hack-arounds > oribiting this problem, and I would be willing to do some work to > smooth it over. > > Is there a github repo for this, or is it a part of python core. In > short, is there any way I can contribute this code into distutils > somehow? distutils is in the core as part of the standard library. The canonical repository is at: http://hg.python.org/cpython/ Submitters should follow the process outlined in the Python Developers' Guide: http://docs.python.org/devguide/ Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMGIbAACgkQ+gerLs4ltQ7cuQCgnfoP8R+jLp5SHncVwbD3+5ac is0An0YZkVXX017wUEiZ1pP3WpLhul+k =M+Em -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 3.0b1 available for preview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 11:09 PM, Jason R. Coombs wrote: > I'm pleased to announce that Setuptools 3.0b1 is now available for > download from the project downloads page: > > https://bitbucket.org/pypa/setuptools/downloads > > This backward-incompatible release contains the changes detailed in > the CHANGES.txt file: > > https://bitbucket.org/pypa/setuptools/src/3.0b1/CHANGES.txt?at=default > > Please give this beta release a try or review the changes for any > impact this might have on your package. I anticipate most users will > find these changes of no consequence, but if there are any issues that > might affect your package that don't have an obvious solution, please > file a ticket. I just tested SubstanceD using virtualenv's built with both Python 2.6.9 and Python 3.3.3. All tests pass, exercising a stack which includes ZODB, the zope.* packages, pyramid, etc. I did see one at-exit failure (during the 'setup.py develop' under 2.6.9), but it was harmless AFAICT. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL7yuwACgkQ+gerLs4ltQ7j8gCfd34nVzU3w/GCVfaxEAzx8jKm gPsAn0gVS/YikXf64JkSr1L/G3n+aoXR =s2z/ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheels on sys.path clarification (reboot)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2014 06:55 PM, Noah Kantrowitz wrote: > If you are going to document this, and it is not going to be > explicitly supported by the spec (it isn't), the _only_ logical thing > is to document that this is undefined behavior and while it works now, > people should not depend on it. Under no circumstance should we > document this as "well it works right now" without guidance about the > fact that it isn't part of the spec and is _not_ a candidate for > future design decisions. If someone would like to propose amending the > spec that can happen separately, but as it stands right now this is > nothing but convenient, undefined behavior. Nick's point in this thread is that zip-importability is a *necessary corrolary* (not an implementation detaiL) of the "no special installers" design choice. - - Given that there is a non-empty set of wheels which can be unpacked to a filesystem-directory tree in a directory on sys.path, and that some of those wheels are already known not to otherwise break zip- importability, it is a logical necessity that such wheels can be put onto sys.path without unpacking. We already have existence proof for this in software being released *by the folks who made these specs*. Noting is as such is the *point* of Nick's change. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLp2hIACgkQ+gerLs4ltQ6VGACgjnYRbgVSs8ceTXNeWTH0zCls yHwAn0/nyDUMRjNl7ARi0bVtkBOeO1nJ =2pvt -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 2.0 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2013 04:40 PM, Antoine Pitrou wrote: > Is there a changelog? https://bitbucket.org/pypa/setuptools/src/f4d6757ae9fa79df03ef6ed070ab8757707fe963/CHANGES.txt?at=default Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKmPi0ACgkQ+gerLs4ltQ6HggCguPzkufm/VmuORsxC5xJ59rwQ yY4An2y622rRFmNFrNOxEit1TED0QpMw =P0Ix -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Handling the binary dependency management problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2013 12:23 PM, Vinay Sajip wrote: > On Mon, 2/12/13, Tres Seaver wrote: > >> The issue is combinatorial explosion in the compatibility tag >> space. There is basically zero chance that even Linux users (even >> RedHat users across RHEL version) would benefit from pre-built >> binary wheels (as opposed to packages from their distribution). >> Wheels on POSIX allow caching of the build process for deployment >> across a known set of hosts: they won't insulate you from the need >> to build in the first place. > > The combinations are number of Python X.Y versions x the no. of > platform architectures/ABI variants, or do you mean something more > than this? Trying to mark up wheels so that they can be safely shared with unknown POSIXy systems seems like a halting problem, to me: the chance I can build a wheel on my machine that you can use on yours (the only reason to distribute a wheel, rather than the sdist, in the first place) drops off sharply as wheel's "binariness" comes into play. I'm arguing that wheel is not an interesting *distribution* format for POSIX systems (at least, for non-Mac ones). It could still play out in *deployment* scenarios (as you note below). Note that wheel's main deployment advantage over a binary egg (installable by pip) is exactly reversed if you use 'easy_install' or 'zc.buildout'. Otherwise, in a controlled deployment, they are pretty much equivalent. > The wheel format is supposed to be a cross-platform binary package > format; are you saying it is completely useless for POSIX except as a > cache for identical hosts? What about for the cases like simple C > extensions which have no external dependencies, but are only for > speedups? I have a lot of packages on PyPI which have such optimization-only speeedups. The time difference to build such extensions is trivial (e.g., for zope.interface, ~1 second on my old slow laptop, versus 0.4 seconds without the extension). Even for lxml (Daniel's original motivating case), the difference is ~45 seconds to build from source vs. 1 second to install a wheel (or and egg). The instant I have to think about whether the binary form might be subtly incompatbile, that 1 second *loses* to the 45 seconds I spend over here arguing with you guys while it builds again from source. :) > What about POSIX environments where compilers aren't available (e.g. > restricted/embedded environments, or due to security policies)? Such environments are almost certainly driven by development teams who can build wheels specifically for deployment to them (assuming the policies allow anything other than distro-package-managed software). This is still really a "cache the build" optimization to known platforms (w/ all binary dependencies the same), rather than distribution. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKcyPsACgkQ+gerLs4ltQ4oBwCgvhoq8ovEn/Bl/0FpBEfI48JY znEAoJElD+R9SPnJXduwjCy7oxWRmcWH =a0TT -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Handling the binary dependency management problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2013 06:38 PM, Paul Moore wrote: > I understand that things are different in the Unix world, but to be > blunt why should Windows users care? You're kidding, right? 90% or more of the reason for wheels in the first place is because Windows users can't build their own software from source. The amount of effort put in by non-Windows package owners to support them dwarfs whatever is bothering you here. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKcjTgACgkQ+gerLs4ltQ7fQQCg0Pfd5tp3vvEsJnJ0aNLNeIXH bVwAn2av6wxVMXEqe4jIQLL+2W4oqQ9G =foOx -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Handling the binary dependency management problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2013 05:17 PM, Nick Coghlan wrote: > I see conda as existing at a similar level to apt and yum from a > packaging point of view, with zc.buildout as a DIY equivalent at that > level. FTR: zc.buildout does nothing to insulate you from the need for a compiler; it does allow you to create repeatable builds from source for non-Python components which would otherwise vary with the underlying platform. The actual recipes for such components often involve a *lot* of yak shaving. ;) Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKcjIMACgkQ+gerLs4ltQ5XlQCeMmoyvAOvJGChhpGOF2Phkut0 nfwAnjj2pbr8bHKfS8+lzt/XorPVNzSe =QmuK -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Handling the binary dependency management problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2013 05:07 PM, Vinay Sajip wrote: > On Sun, 1/12/13, Paul Moore wrote: > >> If the issue is simply around defining compatibility tags that >> better describe the various environments around, then let's just >> get on with that - we're going to have to do it in the end anyway, >> why temporarily promote an alternative solution just to change our >> recommendation later? > > This makes sense to me. We should refine the compatibility tags as > much as is required. It would be nice if there was some place (on > PyPI, or elsewhere) where users could request binary distributions for > specific packages for particular environments, and then some kind > people with those environments might be able to build those wheels and > upload them ... a bit like Christoph Gohlke does for Windows. The issue is combinatorial explosion in the compatibility tag space. There is basically zero chance that even Linux users (even RedHat users across RHEL version) would benefit from pre-built binary wheels (as opposed to packages from their distribution). Wheels on POSIX allow caching of the build process for deployment across a known set of hosts: they won't insulate you from the need to build in the first place. Wheels *might* be in play in the for-pay market, where a vendor supports a limited set platforms, but those solutions will use separate indexes anyway. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKcizYACgkQ+gerLs4ltQ6kKwCfRa5s8XnM5SwlnnIHGGJ8dJSg hPUAn1TLWQNxtbQmPvvMPT2rEmlhCwq5 =xRsn -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Plans for binary wheels, and PyPi and OS-X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2013 04:55 PM, Donald Stufft wrote: > > On Oct 31, 2013, at 4:49 PM, Tres Seaver > wrote: > >> Pip *does* need to allow installing them on those platforms, but >> probably only via explicit paths / URLS (rather than finding them on >> PyPI). > > You can install them just fine on any platform, the only restrictions > are PyPI won?t let you upload them, and pip won?t try to install them > from pypi.python.org. Excellent -- sorry I misunderstood. AFAICT, you could leave that restriction in place for ever for Linux. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJy10kACgkQ+gerLs4ltQ5C0QCePWr4hX6zTff9hyCO9+w5s0Ac R8sAn11NPAr3d+SCpricLcdLOhtk/nmp =V/rv -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Plans for binary wheels, and PyPi and OS-X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2013 05:52 PM, Eric V. Smith wrote: > I'm more than happy to build them myself on a dedicated build > machine. Right -- that makes them back into caches. ;) You can safely deploy them because you know the architecture / libc / etc. against which you built them. They are highly unlikely to be useful to anyone *else*, however, except by accident. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJy1vwACgkQ+gerLs4ltQ7HqQCgs3toEwtRSn5q+USRXdOWDB+C dusAn0fSfRyUmRSvqGQ3IUh1Kl6Jh36X =OCEp -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Plans for binary wheels, and PyPi and OS-X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2013 02:24 PM, Donald Stufft wrote: > To be honest the same problems likely exists on Windows, it?s just > less likely and the benefits of prebuilt binaries greater. For all platforms *except* Windows, wheels are essentially caches -- there is no real reason to distribute them via PyPI at all, because OSx and Linux develpoers will have tools to build them from sdists. Pip *does* need to allow installing them on those platforms, but probably only via explicit paths / URLS (rather than finding them on PyPI). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJywmwACgkQ+gerLs4ltQ5P/ACfXcMJj4dmnlNJEccZ8gxi8FLR GrQAoLxxgeVnKRvuoscR6GuabwGxfsnF =gZW1 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] URL Structure of Packages URLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2013 09:19 AM, Donald Stufft wrote: > I was wondering if anyone was aware of anything that relies on the > current structure of package urls, namely: > > /packages/source|any|etc/D/Django-1.0.tar.gz? > > I would like to change this but before I work up a concrete plan for > people to comment on and discuss I'm trying to figure out what, if > anything, depends on that current structure. Any such change should leave behind "rewrite rules" which 301 to the new, "blest" URLs. #dontbreaktheweb and all that. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJVpfAACgkQ+gerLs4ltQ6rhwCffZISAc+VDiqX5NQ/3ET9inJp daAAmgNsHb/0vIVjSTMLrxEGT9S4yodT =2TOU -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deviation between distutils and setuptools over package_data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/20/2013 09:11 AM, Sebastien Douche wrote: > On Fri, Sep 20, 2013 at 2:15 PM, Jim Fulton wrote: >> Did setuptools recently learn about git? > > Nop. I use setuptools-git regularly without problems. >> I would love an option to ignore VCS and let me specify what I want >> *explicitly*. > > Or remove the handling of VCS? - -1. I haven't yet tried Marius' tool, but manually maintaining MANIFEST.in is an unaceptable bug magnet. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlI8WLwACgkQ+gerLs4ltQ4SIgCgh2dRMexciWxnaJBFrU700PDl dOkAoNUNELNFj9Ee0T+mD6ajC3FvQ8xV =FAe6 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2013 09:57 PM, Daniel Holth wrote: > One of the most important packaging insights to understand is that > distutils is in fact worse than setuptools. It is badly outdated, > poorly extensible, and too complex to ever re-implement in a > compatible way. It is not better before the monkey patching. In a > perfect world it should be removed from the standard library too > except that removing distutils would be too impractical. > If you can believe that distutils, not setuptools, is the problem we > are trying to recover from, then the monkeypatching strategy may make > more sense. Amen! Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIhYiIACgkQ+gerLs4ltQ52SwCcDd/Nt8ETGsLIpxbiksYiayfO 59gAn1VxLMvZq4akWuzJsdCNUlBUUxGh =DFtl -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2013 05:00 AM, Nick Coghlan wrote: > PJE and Jason were probably the only other current distutils-sig > participants familiar enough with setuptools and pkg_resources to > understand the distinction between that aspect, the default version > handling and the activation API There are lots of folks here who have been building tooling on top of eggs for almost a decade now. Perhaps those who *do* grok how that stuff works (I'd be willing to guess a lot more than the three of you and myself) weren't alarmed by you proposal. Oophobia is not ubiquitous. :) Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIcxDEACgkQ+gerLs4ltQ4qCgCfQKtjEAQkx7XnkQS8A8Q767E6 lnwAoNJAcSDTbN6I1DW2DZAzC3lMvolQ =AeYU -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2013 10:51 AM, Donald Stufft wrote: > I've personally gotten or seen more complaints over the naming of a > variable in the config file then I have over any changes we've made. > The runner up to that is the fallout from switching to requiring > verified SSL. The past few months have generated a *lot* of teeth-gnashing / hair-pulling, especially among "downstream" developers (those unlikely to be reading this SIG): - - HTTPS-only PyPY - - Distribute / setuptools merge, e.g. cratering folks who use a distro-managed 'python-distribute' package. - - Pip's new backward-imcompatible "final releases by default". I think we are going to be in a much better place for all that, but let's not deny the pain involved for *everybody* in getting there. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlH2n+EACgkQ+gerLs4ltQ6megCeN8V8IN4OT6rWfZg1tw1GtUaO 2jwAoLRXzLyjjMbiLrcfqLG0Ge1NQnMq =7ufm -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Shebang lines, /usr/bin/python, and PEP394
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/2013 03:32 PM, Barry Warsaw wrote: > If you're installing a script into a virtualenv, it's better to > rewrite the shebang to use the executable that was used to install > it. Exactly -- the script likely won't run at all outside the environment where its dependencies are installed. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHy4E0ACgkQ+gerLs4ltQ57XgCg1JsuCk2zxOpJyWNoHv1V/0h/ Y1EAoND2clmyfdHjqVY/3p+PafWXM0Lp =uzfB -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Best practices for optional C extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2013 09:14 AM, Ben Darnell wrote: > I'd like to add a C extension to speed up a small bit of code in a > package (Tornado), but make it optional both for compatibility with > non-cpython implementations and for ease of installation on systems > without a C compiler available. Ideally any user who runs "pip > install tornado" on a system capable of compiling extensions would get > the extensions; if this capability cannot be detected automatically > I'd prefer the opt-out case to be the one that requires non-default > arguments. Are there any packages that provide a good example to > follow for this? > > PEP 426 uses "c-accelerators" as an example of an "extra", but it's > unclear how this would work (based on the equivalent setuptools > feature). There doesn't appear to be a way to know what extras are > requested at build time. If the extra required a package like cython > then you could build the extension whenever that package is present, > but what about hand-written extensions? Extras are also opt-in > instead of opt-out, so I'd have to recommend that most people use "pip > install tornado[fast]" instead of "pip install tornado" (with > "tornado[slow]" available as an option for limited environments). zope.interface subclasses the 'build_ext' command so: - %< - from distutils.command.build_ext import build_ext from distutils.errors import CCompilerError from distutils.errors import DistutilsExecError from distutils.errors import DistutilsPlatformError class optional_build_ext(build_ext): """Allow the building of C extensions to fail. """ def run(self): try: build_ext.run(self) except DistutilsPlatformError as e: self._unavailable(e) def build_extension(self, ext): try: build_ext.build_extension(self, ext) except (CCompilerError, DistutilsExecError) as e: self._unavailable(e) def _unavailable(self, e): print('*' * 80) print("""WARNING: An optional code optimization (C extension) could not be compiled. Optimizations for this package will not be available!""") print() print(e) print('*' * 80) - %< - Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHitjoACgkQ+gerLs4ltQ7SJQCgrhgN58g9ztFPEkFAOM49Wu4p RpQAoLnboKietjTx3eXho1kyRvH3r2uN =qWRK -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Current status of PEP 439 (pip boostrapping)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2013 08:25 AM, Nick Coghlan wrote: > I think we need to flip the dependencies so that pip as the installer > has all the essential code for installation from PyPI and then > setuptools and distlib depend on that pip infrastructure. No need to > add anything to the standard library prematurely when we can add it to > pip instead. - -1. That would effectively mean inlining the bulk of setuptools' code into pip (which is just a UI / policy shim over it). You might as well just have your bootstrapper install both pip and setuptools and be done Unless distlib (or something like it) lands in the stdlib with enough features to support a setuptools-less pip, of course. At-which-point-the-State-will-wither-away'ly, Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHhbLkACgkQ+gerLs4ltQ51fQCfZrmZN5mJKrtoGFTk0YqQrBHd F/IAnRp6XjoU4SpXZ4v3Uz6iOBrCZZZn =gSA5 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2013 11:20 PM, Donald Stufft wrote: > doesn't "PyEnv" which is bundled with Python 3.3+ replace virtualenv? > What's the purpose of including virtualenv in the bootstrap? > http://www.python.org/dev/peps/pep-0405/ Environments generated by pyvenv lack setuptools, which makes them un-useful compared to those generated by virtualenv. Virtualenv is also useful across the important set of Python versions (2.6, 2.7, 3.2, 3.3), which pyvenv (or any shipped-in-core varieant) can never be. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHdGyYACgkQ+gerLs4ltQ5gMQCfZuHj7XyIWv+Wru0rA5VTk//1 JxkAoILDxz0Yn8zOLWP0jOGCc/gDikY8 =15US -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout/setuptools/distribute unhelpful error message (0.7.x issue?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2013 03:08 AM, Chris Withers wrote: > > I don't see any distribute in there, and I don't know where it might > be... 'pkg_resources' (/usr/lib/python2.6/dist-packages/pkg_resources.py) comes from either setuptools or distribute -- in your case, distribute (probably via a 'python-distribute' Debian package, given that path). Either you need to get that system pacakge updated, or else removed, or else insulate yourself from it (e.g., with a 'virtualenv --no-setuptools' or a self-built Python). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHZbdIACgkQ+gerLs4ltQ7y1ACfSuEQBXY/THSNDsoLysgORTQv HeQAoI5TH6WOqNG3TR9Fuu4VKURpeil2 =kkLS -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] pip and virtualenv release candidates
On 07/03/2013 01:28 AM, Marcus Smith wrote: > 3) Older pip's can not currently upgrade distribute to setuptools > (until distribute-0.7.3 is released on ~July-7th) > (for more upgrade details: > http://www.pip-installer.org/en/latest/installing.html#requirements) FWIW, the following works to update a distribute-baesd virtualenv to the new setuptools / vr: $ bin/easy_install \ --find-links https://bitbucket.org/pypa/setuptools/downloads/ \ -U distribute No-looking-back'ly, Tres. -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2013 04:44 PM, Jason R. Coombs wrote: > I had to pull distribute 0.7 because older versions of pip couldn't > handle the upgrade. You mean 'pip install -U distribute' fails with distribute 0.7? This works for me in a brand-new virtualenv w/ distribute: $ bin/pip install \ --find-links=https://bitbucket.org/pypa/setuptools/downloads/ \ -U distribute > I'll be re-adding distribute 0.7 back to PyPI following the new > release of pip. Can you test by pointing to the bitbucket downloads in > the short term? > > Can you tell me about what issues the buildout users are experiencing? > Are they trying to upgrade a buildout from distribute to setuptools? > Or is there an issue with creating new buildouts against the latest > setuptools? No issue with the latest setuptools. The "prevent setuptools installation at all costs" behavior of distribute 0.6.x kills the buildout (or its bootstrap) which tries to install setuptools 0.7.2. If there was a clean way to upgrade from distribute 0.6 before running the bootstrap, that would be enough: but then, that was what distribute 0.7 was supposed to do. :( > I'm hesitant to release Distribute 0.7 because even the latest version > will break the 'easy_install' scripts for users who upgrade via pip. > Actually, on second thought, pip users might consider that a feature. pip users can't spell easy_install, so you should be safe. :) > If there's going to be a re-release of distribute 0.7, it'll need to > be coordinated with the pip and virtualenv releases, which we're > planning for the weekend after next (Jul 6). I know that's a long > time, but I'm hoping there's a suitable workaround for buildout. If > not, then getting an updated distribute (and possibly pip) out sooner > (even without immediate) virtualenv support might be possible. Where are the problems pip users reported with distribute 0.7 archived? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHItfQACgkQ+gerLs4ltQ5PWQCdHenszGzMEbOXgzmHyIKK/EwW X4oAnRE7uAYmBQE97gabYiWFbjRA1Egz =/k4B -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 12:22 PM, Jason R. Coombs wrote: > Additionally, I released Distribute 0.7 to PyPI. This means that users > who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply > invoking `easy_install -U distribute` (or `easy_install > "distribute>=0.7"`). Windows users should use `easy_install-script -U > distribute` (to avoid "file in use" errors on easy_install.exe). Jason, the cheeseshop doesn't show a distribute 0.7 release. We have folks who can't easily test the new version of zc.buildout because they are stuck on a setuptools-denying version of distribute. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHIfl8ACgkQ+gerLs4ltQ7PaQCgruExzWYv6I9qw6LQSx5RwnzH hPQAoI1Ta2lImcTdgHzq52U3N2eKv5o3 =kyNO -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Post-merge setuptools Python 3 single-codebase port available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 12:35 PM, Vinay Sajip wrote: > Following the setuptools/distribute merge, I've updated my single > codebase port of the merged setuptools at [1]. Source of my repo is > available at [2] (single-codebase branch). Travis integration has been > set up; results are at [3]. > > Currently, all tests are passing for 2.5, 2.6, 2.7, 3.2, and 3.3. > > For installation into PEP 405 venvs, a wheel has been set up at [4]. > > Feedback welcome. Thank you for your work! +100 for an immediate merge. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG8oTgACgkQ+gerLs4ltQ5/FwCgiYZt/q+t6t2emibspuUAYDLG r4UAn07mxKKQWvpNhG1aLgLZsZ2i2WIO =/7Yf -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] error using easy_install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 02:29 AM, Ethan Furman wrote: > My setup.py: > > -- 8< -- > from distutils.core import setup > > long_desc = open('enum.rst').read() > > setup( name='stoneleaf.enum', version='1.0.1', > url='https://pypi.python.org/pypi/stoneleaf.enum', packages=['enum'], > package_dir={'enum':''}, package_data={'enum':['enum.rst', 'enum.pdf', > 'test/test_enum.py', 'test/py2_test_enum.py', > 'test/py3_test_enum.py']}, license='BSD License', description='Python > 3.4 Enum backported to 3.3, 3.2, 3.1, 2.7, 2.6, 2.5, and 2.4', > long_description=long_desc, provides=['enum'], author='Ethan Furman', > author_email='et...@stoneleaf.us', classifiers=[ 'Development Status > :: 5 - Production/Stable', 'Intended Audience :: Developers', 'License > :: OSI Approved :: BSD License', 'Programming Language :: Python', > 'Topic :: Software Development' ], ) -- 8< > -- > > Error trying to install it with easy_install after uploading it to > PyPI: > > ethan@hydra:~$ sudo easy_install stoneleaf.enum Searching for > stoneleaf.enum Reading http://pypi.python.org/simple/stoneleaf.enum/ > Best match: stoneleaf.enum 1.0.1 Downloading > http://pypi.python.org/packages/source/s/stoneleaf.enum/stoneleaf.enum-1.0.1.zip#md5=c41abd7ad04f11e8b545cfca7758a4f2 > > Processing stoneleaf.enum-1.0.1.zip > Writing /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/setup.cfg > Running stoneleaf.enum-1.0.1/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/egg-dist-tmp-IpvhLD > error: Setup script exited with error: can't copy 'num.rst': doesn't > exist or not a regular file > > > There is no 'num.rst' file in the package -- it should be 'enum.rst'. > > Any ideas? Is this the right place to post? This is the right place. Your 'package_data' declaration is getting munged:: > /tmp/stone/stoneleaf.enum-1.0.1/build/bdist.linux-i686/egg/setuptools /command/build_py.py(80)build_package_data() -> self.copy_file(os.path.join(src_dir, filename), target) (Pdb) l 75lastdir = None 76for package, src_dir, build_dir, filenames in self.data_files: 77for filename in filenames: 78target = os.path.join(build_dir, filename) 79self.mkpath(os.path.dirname(target)) 80 ->self.copy_file(os.path.join(src_dir, filename), target) 81 82 83def analyze_manifest(self): 84self.manifest_files = mf = {} 85if not self.distribution.include_package_data: (Pdb) pp self.data_files [('enum', '', 'build/lib/enum', ['num.rst', 'num.pdf', 'est/test_enum.py', 'est/py2_test_enum.py', 'est/py3_test_enum.py'])] Looking at the 'build_py' step, this line is problematic: package_dir={'enum':''}, When I change it to: package_dir={'enum':'.'}, then the install succeeds. I would probably just make an 'enum' subdir, move the files into it, and be done with it ('setup.py' isn't logically part of the package: it is in the wrapper). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG8oNUACgkQ+gerLs4ltQ4axQCgh1YAyvqC/ZRJs1V6U4jQ66as 9VQAnRmJqhFINjzjCx2eftJfALKj/vsc =o/a+ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2013 05:27 AM, Chris Withers wrote: > On 10/06/2013 18:57, Tres Seaver wrote: >> Works for me: >> >> $ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts ="> >> buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py >> ... $ /opt/Python-2.5.x/bin/python bootstrap.py > > Try with 2.7, and also try going from 1 to 2 and back again by > switching bootstraps. > > There's likely something funky going on (.installed.cfg, develop-eggs > or some other goat sacrifice in bin/) but it definitely happened. That same recipe works with 2.7. In general, the presence of .installed.cfg should be thought of as problematic for any big surgery (like changing bootstraps, or major versions of buildout), because it hampers repeatability in order to make the build run faster. When in doubt, remove .installed.cfg and re-run buildout after any such change. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG3sSMACgkQ+gerLs4ltQ4ExACfaXdJ1n3jFV+W0HmuNuKB1SDN 8W0Anj3WVTQebSJ71K1Q488KCr5JK/gd =NsB8 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/2013 06:22 AM, Chris Withers wrote: > Hi All, > > So, having given up on buildout 2 for this package again (need for 2.5 > support) I dutifully put in the bootstrap.py from buildout 1: > > curl http://downloads.buildout.org/1/bootstrap.py > bootstrap.py > > python2.5 on my mac didn't work, thanks to a broken system python, so > on to 2.6, which appeared to go okay except: > > buzzkill:checker chris$ bin/nosetests zc.buildout 2 needs distribute, > not setuptools. Are you using an outdated bootstrap.py? Make sure > you have the latest version downloaded from > http://downloads.buildout.org/2/bootstrap.py > > Great... Wonderful... I thought 1/bootstrap.py was supposed to pin to > buildout 1 for you without the need for any other voodoo? Works for me: $ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts =" > buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-\ 0.6c11-py2.5.egg Creating directory '/tmp/withers/bin'. Creating directory '/tmp/withers/parts'. Creating directory '/tmp/withers/eggs'. Creating directory '/tmp/withers/develop-eggs'. Getting distribution for 'setuptools'. /opt/Python-2.5.5/lib/python2.5/distutils/dist.py:263: \ UserWarning: Unknown distribution option: 'src_root' warnings.warn(msg) Got setuptools 0.7.2. Generated script '/tmp/withers/bin/buildout'. $ bin/buildout $ ls eggs setuptools-0.7.2-py2.5.egg zc.buildout-1.7.1-py2.5.eg Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG2E3oACgkQ+gerLs4ltQ4n0ACgnIJb6c4Wf/3i+sY57FY1BRGa emgAoJdTohJwbWmhGCvhzt/Pbv9AJTGT =Bn58 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 10:28 PM, Donald Stufft wrote: > > On Jun 9, 2013, at 9:51 PM, Nick Coghlan wrote: > >> On 10 June 2013 03:49, Jason R. Coombs wrote: >>> I'm leaning toward uploading it to BitBucket downloads as part of >>> the release script. >>> >>> I'll put ez_setup.py for 0.7.2 in downloads for now. You can >>> assume that's where the permalink will be. >> >> I think that's a good way to publish it securely to the PSF >> infrastructure team (at least for now) >> >>> If anyone has a better suggestion, please raise it. >> >> As others have suggested, we should work with Donald and Noah to >> get the bootstrapping script an official home somewhere on >> pypi.python.org. >> > If you want it under pypi.python.org it'll probably need manually > sent to myself for the time being. I believe it could easily be hosted > via python hosted.org though without needing manual intervention. I'm not wedded to anyplace in particular. Having the bootstrap needed to make effective use of PyPI hosted on PyPI itself makes a lot of sense to me. Maybe under a URL like this one? https://pypi.python.org/bootstraps/ez_setup.py The main key is that the URL should be immutable (so we can doucment it widely, and use it in scripts) and have availability as good as the cheeseshop (I'm not knocking Bitbucket in particular). If the file were copied into the Sphinx docs uploaded to pythonhosted.org, that would probably work just as well. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG1PO8ACgkQ+gerLs4ltQ64WQCeO0tVhPBjlmzvtzdBx0C4V5Hr lVAAniVJ4XuAnPfV7NXT7KvcextrrTaJ =ILKd -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 01:49 PM, Jason R. Coombs wrote: > Is the bitbucket 'raw' source not suitable? It uses the version tag to > indicate precisely which file is appropriate, which means we don't > have to redundantly host that file elsewhere. > > Oh, I think I see - there's no link that doesn't change - you want a > permalink for the latest stable release. I hadn't considered that use > case, but you're right - we do want that. Perhaps the file could be > added to pythonhosted.org alongside the documentation. Or maybe it > belongs on bitbucket in `downloads`. > > I need to figure out which is more straightforward w.r.t. > authentication. The distribute process was messy because it involved > SSH and keys that had to be manually managed. > > I'm leaning toward uploading it to BitBucket downloads as part of the > release script. > > I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume > that's where the permalink will be. > > If anyone has a better suggestion, please raise it. I would prefer a URL on a host managed by the Python infrastructure team: either PyPI or the pythonhosted org. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG1B2sACgkQ+gerLs4ltQ7H8gCdE/g1UBfr74s7v5tmuHLXdktx 3L0AoMxPG48F5KM8Ae+v5A1g9nU2B4To =pTON -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2013 12:22 PM, Jason R. Coombs wrote: > On behalf of the PYPA, I'm excited to announce that Setuptools 0.7 is > now official and complete. > > Released to PyPI, Setuptools 0.7.2 is now available for all to see by > default (https://pypi.python.org/pypi/setuptools/). Users of > Setuptools 0.6 may upgrade by simply running `easy_install -U > setuptools`. > > Additionally, I released Distribute 0.7 to PyPI. This means that users > who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply > invoking `easy_install -U distribute` (or `easy_install > "distribute>=0.7"`). Windows users should use `easy_install-script -U > distribute` (to avoid "file in use" errors on easy_install.exe). > > The documentation for Setuptools 0.7.2 has been uploaded to > https://pythonhosted.org/setuptools and includes the notes about the > merge in addition to the official documentation. > > Please report any issues at the project page > (https://bitbucket.org/pypa/setuptools). Thanks for all the work that went into this release. I'm working to get buildout 2.0 to use the new setuptools, and need to encode a more-or-less permalink URL for 'ez_setup.py' -- do we not have a better URL for it than the Bitbucket 'raw' source? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG0t74ACgkQ+gerLs4ltQ6Q5wCg2hMoLBxfv6NIR/DTOUjdBNei kVUAnjZ9ua2gRpwXyeRw/i1CIBPeV9e0 =Ksc7 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Preemptive Apology for Volume of Mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/2013 11:13 AM, Donald Stufft wrote: > I'll see what I can whip up. Would a script be ok? Sure -- I'm fine with whatever works. Thanks! Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGuBUMACgkQ+gerLs4ltQ4+QACeKSfBL2qVzMtphRX+JZ3cmNPQ 0XcAniXUgAIlLaH729gO3GItgUzD0kMW =NVwu -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Preemptive Apology for Volume of Mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/2013 01:46 AM, Donald Stufft wrote: > 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. I don't mind the 250 or so messages, but I'd *really* like to get a "bulk change" UI to set all 250 to #1 at once -- there is no way I'm going to take the time to clickety-click through them and fix them by hand. Without such a UI, I guess I'm just going to wait for the auto-conversion. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGuA6UACgkQ+gerLs4ltQ5CuACeMst3VewOCkGMx82Dx62PTtan Bj0AnRpSCCymJGMdxjuVx0/klKqIYxfo =IELQ -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 <http://bugs.python.org/setuptools/issue150> ___ ___ 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 'setuptools<0.7dev'. [1] https://bitbucket.org/pypa/setuptools/issue/8/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://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
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 Design"http://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
-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 Design"http://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: 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 Design"http://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] Sooner or later, we're going to have to be more formal about how we name packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGrhjEACgkQ+gerLs4ltQ7jnQCfYokgj1vHL/pcun2PYmsP6EYD ei4AoJ0AhzbIckRY+mGtIk89qXqaFjY9 =Mqzk -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2013 06:41 PM, Jim Fulton wrote: > I hope no one is proposing removing a project simply because someone > hasn't released a new (after initial) release in some period of time. Certainly not I: I'd just like to prevent "squatters" (no matter how well-intentioned, Withers!) from tying up a project name indefinitely. Code talks, as it were: release something or take your marbles and go home. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGqky0ACgkQ+gerLs4ltQ74iwCgqSr4TqKC/ktgU0XlsDKedp2i 3ZwAnRnuuEX2imZlVs2CT54faUZFYo6l =qReS -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2013 09:18 AM, Lennart Regebro wrote: > I'd be OK with after six months automatically removing packages that > has only one owner/maintainer, and that owner/maintainer has no other > packages, and the package has no available downloads, and no contact > information on either package nor registered user. Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGpCWIACgkQ+gerLs4ltQ6e5wCbBm6t1T8a5ffPGBEFV0K3s3Fg jA8AoLVfTLCrSy6aCAbogcEouQc8H8Ak =bZTd -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Announcing Setuptools 0.7b3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/25/2013 04:40 PM, Jason R. Coombs wrote: > Setuptools and Distribute are now merged, and the new home can be > found at https://bitbucket.org/pypa/setuptools. > > Issues for Distribute are still being maintained at its old home, but > releases are now made from the 'distribute' fork on the setuptools > repo. Future releases of Distribute (if any) will be maintenance > only. > > The new setuptools, which is designed to be largely compatible both > with Distribute and Setuptools can now be downloaded on the > 'downloads' page of the PyPA site: > > https://bitbucket.org/pypa/setuptools/downloads > > For those familiar with setuptools/distribute, the upgrade process is > pretty straightforward: remove your old versions of distribute and/or > setuptools and install the latest. To install the latest, extract the > .tar.gz, and run setup.py in the target environment. Windows .msi > installers have been provided as well. Ez_setup.py will not yet work > until the official release is made to PyPI. > > I encourage all of those with experience or interest in packaging to > try out the new setuptools in your environments. Test it against your > tool chain. Provide feedback and file issues in the project site. > > This limited public release is provided as an advance release prior to > the full public release. Assuming there are no reported blocking > issues, a final 0.7 release will be made to PyPI in the coming weeks. Congratulations, and thanks to the PyPA developers for coming together to produce this unified release. FWIW, I was just able to update a setuptools 0.6 virtualenv via: $ bin/easy_install -U https://bitbucket.org/pypa/setuptools/downloads/setuptools-0.7b3.tar.gz For a distribute-based virtualenv, I had to delete the 'distribute' entry in 'site-pacakges' after running the 'easy_install' command. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGhPPYACgkQ+gerLs4ltQ5zngCg1iTC2xwLcvZT/MHSi8bNlFDl clgAnjXOCbXqN0rW1ihwWEBUCFzEFC5U =MF9s -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install failed to install numpy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 04:12 AM, Huiqun Zhou wrote: > I'm trying to install numpy, but got the following error message. > What's wrong? NumPy and SciPy aren't setuptools-compatible. You will need to follow the directions on the SciPy site: http://www.scipy.org/Installing_SciPy Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGZMdcACgkQ+gerLs4ltQ6/sgCgu9oul6B8Rj9TzFxTH7VBVDxI plEAnAr6VcU6VmAofTSYHomPwXoNGh6y =NLjX -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 438 - Transition Phase 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/2013 08:50 PM, Donald Stufft wrote: > Phase 1 of PEP 438 (http://www.python.org/dev/peps/pep-0438/) has > begun. > > Deployed to production PyPI is: - New packages default to > pypi-explicit - Old packages default to pypi-scrape-crawl - Package > Maintainers can select which hosting mode to use - Package Maintainers > can control what urls show up on their /simple/ index > > What's still happening: > > - All existing packages will be processed to determine if they host > files on PyPI, if they host files externally but link directly, or if > they Host files externally and require scraping the home or download > url pages. - Taking the data obtained from processing email users to > tell them if their package can be moved to a more restrictive download > option (e.g. all their versions are installable directly from PyPI, or > from a direct link from PyPI). - A Month after that actually moving > them to their detected new hosting mode (if possible on a per project > basis). I would be glad to update all my packages to explicit mode, but would prefer to be able to do that in a single batch (clicking through to 250 or so to set it will be tedious). It would be good to automate removing all external URLs previously sniffed from the long-description, too. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGY5dkACgkQ+gerLs4ltQ5q7ACeOz96JWSdd7+cC8LNTlU7YzpF mIEAmwVURbJGsoYQPGBns+1XK4lY3bwN =/Uyr -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 504 timeouts on pypi.python.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/2013 03:16 PM, Donald Stufft wrote: > > On May 17, 2013, at 6:29 PM, Tres Seaver > wrote: > >> Both in the web interface and in registration / upload of releases. >> > Is this still happening to you? This afternoon I was able to register / upload the release for which I noticed the problem yesterday. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGX7l4ACgkQ+gerLs4ltQ6hLgCgw0eK/PNjmAWz12+LZqnLQfJt TgYAoIzreHKL8WxXAzNMEyyNBuknC7h/ =djJM -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 504 timeouts on pypi.python.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Both in the web interface and in registration / upload of releases. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGWr2IACgkQ+gerLs4ltQ5bAwCffg+Zn0MwHPaxrALbCSbHXeRP 1LEAoKMyu/z9nb1+nBSktEE0spAWYQ3W =QIvr -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distil 0.1.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2013 02:24 PM, Noah Kantrowitz wrote: > People expect "package install" as root to work like every other > package system (yum, apt, take your pick) where they run "sudo pip > install a b c d" and then run their app as a service-specific user. I don't know any of those people: either folks have learned *not* to install as root, or else they run as root too. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGEAP4ACgkQ+gerLs4ltQ6odACfXcO7KHBYvPJhWOZCXMtMTZsn bxIAn3j9jwRe70de+O0mIY4K2kfDrfzs =WgtN -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP: Improving Python ZIP Application Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/30/2013 03:22 PM, Daniel Holth wrote: > Python ZIP Application Support - > https://docs.google.com/document/d/1MKXgPzhWD5wIUpoSQX7dxmqgTZVO6l9iZZis8dnri78/edit?usp=sharing +1, > but I think this actually belongs on python-dev (AFAICT it is unrelated to distutils, setuptools, etc.) Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFXbbQACgkQ+gerLs4ltQ5+OgCgqP75xYWG8TGxiT3efvjZWe5U YT4AoKTQJMhkbkU4KBoqmhOCDUl+5/Xo =ERp8 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] Merge catalog-sig and distutils-sig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2013 04:32 PM, PJ Eby wrote: > On Thu, Mar 28, 2013 at 3:43 PM, Donald Stufft > wrote: >> On Mar 28, 2013, at 3:39 PM, PJ Eby wrote: >>> Can we do it by just dropping catalog-sig and keeping >>> distutils-sig? I'm afraid we might lose some important >>> distutils-sig population if the process involves renaming the >>> list, resubscribing, etc. I also *really* don't want to >>> invalidate archive links to the distutils-sig archive. >>> >>> All in all, +1 on not having two lists, but I'm really worried >>> about "breaking" distutils-sig. We're still going to be talking >>> about "distribution utilities", after all. >> >> Worst case I'm sure subscribers can be transferred and the existing >> archive kept intact. > > That's a great way to have a bunch of people complaining that they > never subscribed to packaging-sig, not to mention the part where it > breaks everyone's mail filters. > > I really don't see any gains for renaming the list. It's not like we > can go and scrub the entire internet of references to distutils-sig. Not to mention breaking the gmane.org gateway, and those of us who sip the firehose there instead of trying to swallow it via e-mail. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFUuS4ACgkQ+gerLs4ltQ4zXACguC0D2F3EEE7GT4DGXRa08hy7 FdYAoM56YpHef9J0ScKOdY2OHv/48LOv =3UtH -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Builders vs Installers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/26/2013 09:12 PM, PJ Eby wrote: > (Some tools do check for the *existence* of a PKG-INFO, like PyPI's > sdist upload validation, and the various egg formats require a file > *named* PKG-INFO, but AFAIK nothing commonly used out there actually > *reads* PKG-INFO or gives a darn about its contents, except for that > version usecase mentioned above.) I do have a tool (named 'pkginfo', funnily enough) which does parse them: https://pypi.python.org/pypi/pkginfo http://pythonhosted.org/pkginfo/ I use it in another tool, 'compoze', which allows me to build "cureated" indexes from versions installed locally (e.g., after testing in a virtualenv): https://pypi.python.org/pypi/compoze/ http://docs.repoze.org/compoze/ Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFTKBcACgkQ+gerLs4ltQ4x/wCfZsp/p60ELrQvTCXfdPMhuK1E qJQAoJXvTlTSo1iy/KxylnuizPodbr25 =IJ6t -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP439 and backward compat / easy_install / distlib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/26/2013 05:28 AM, Ronald Oussoren wrote: > > On 25 Mar, 2013, at 19:16, PJ Eby wrote: >> >> >> Also, as far as detecting the need for setuptools, I think that can >> be done just by noticing whether the PKG-INFO included in an sdist >> is metadata 2.0 or not. If it is, then setuptools should be >> explicitly declared as a build-time dependency, otherwise it's not >> needed. If it's an older metadata version, then you probably need >> setuptools. > > Is it even necessary to automaticly install setuptools? > Setuptools-using package are supposed to use ez_setup.py, or > distribute_setup.py for distribute, to ensure that the setuptools > package is available during setup. No, they are not. That usage was for bootstrapping in an era when setuptools was not widely presetn. Most packages have *removed* those files today. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFRvPAACgkQ+gerLs4ltQ6XhgCgknMlM9drnL5KJKSvoEcuoKqw 60gAn1QyyUersaUdKXbJrpnJuu3AXkzz =i63/ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] self.introduce(distutils-sig)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2013 06:13 AM, Paul Moore wrote: > Another nice tool would be some sort of Windows build farm, where > projects could submit a sdist and it would build wheels for a list of > supported Python versions and architectures. That wouldn't work for > projects with complex dependencies, obviously, but could cover a > reasonable-sized chunk of PyPI (especially if dependencies could be > added to the farm on request). The Zope Foundation pays hosting charges for a box which runs Windows tests for ZF projects, and also builds and uploads Windows binaries (eggs and MSIs) for them when they are released. http://winbot.zope.org/ As an example, look at any recent zope.interface release, e.g.: https://pypi.python.org/pypi/zope.interface/4.0.5#downloads Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFKAP0ACgkQ+gerLs4ltQ6UZwCgkxfOtrArGn/F5dKPk6+QepWV 7jYAniBreYijRKhevNS6rDUteePNzfZW =m0LP -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools-Distribute merge announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the announcment, and especially thanks to all those who have worked on setuptools and distribute. Particular thanks to PJE for having both devised the thing and worked out how to get the community to adopt it. I'm looking forward to the packaging BoF now, instead of dreading it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFCCosACgkQ+gerLs4ltQ7qNgCgx+PDk8GYdmVIq1fbGdvqFt6K EaEAniahF//OJkZQ/LVnJx6m1DqS0r+D =0P09 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Add optional password_command .pypirc value
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 12:57 PM, Donald Stufft wrote: > If you're uploading via SSH you'll open a SSH tunnel and then POST to > PyPI over that tunnel. That isn't a hard requirment. The PyPI software could add a command-line script used for uploads which depended on the identity indicated by the SSH-authenticated session. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlE6z+MACgkQ+gerLs4ltQ6DggCfZ62QIeUlx5A7A5cnuwU5jTqJ pN8AoN0T0P20qwo5r5p7aheyYi3cGL2L =SdYC -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2013 04:20 AM, Marius Gedminas wrote: > On Tue, Feb 26, 2013 at 09:17:29AM +, Paul Moore wrote: >> On 26 February 2013 06:21, Chris Withers >> wrote: >>> File "./setuptools/dist.py", line 103 except ValueError, e: ^ >>> SyntaxError: invalid syntax >>> >>> Can other people reproduce this? When was that Python 3 >>> incompatible except clause introduced? >> >> I quite often see this, it's usually because something that pip is >> doing (building the metadata/dependency stuff, the actual code >> build is fine) is failing to run 2to3. >> >> I can't offer anything in the way of a fix, I'm afraid... > > How hard would it be to rewrite distribute to use a common language > subset instead of relying on 2to3? The sheer number of developer hours saved by not waiting for the 2to3 run every time a Py3k virtualenv is created should dwarf whatever effort is involve. Any volunteers to "take on for the team"? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEs/CAACgkQ+gerLs4ltQ6oEgCcDobQyI2TbW5Ev0NDtxAOqSlJ GBwAn3F4NMJ9nzY1/xmkxcvJdW8hceYp =Bbmr -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2013 04:53 PM, Maurits van Rees wrote: > Is the develop-eggs directory always cleaned up during a buildout run > so only the eggs in the 'develop' option are listed there? Yes. See: https://github.com/buildout/buildout/blob/master/src/zc/buildout/buildout.py#L438 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDx5XgACgkQ+gerLs4ltQ7KRgCfSpy6MMfZtlqOa5JNhOTH5opj lJ0An2qCMPazGZIG3YuVeFSfaE2fZpwG =PEaD -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files => resources ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2012 10:21 PM, PJ Eby wrote: > On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren > wrote: > >> >> On 19 Nov, 2012, at 20:26, PJ Eby wrote: >>> >>> >>> Data files should never be installed to package directories. But >>> I'm >> not aware of any good reason why resource files should ever be >> installed anywhere *else*. >> >> To be (too) snarky: because the FHS says so. >> > Less snarky, Linux distributors try to keep simular files together > (for >> example storing all gettext translations together in >> /usr/share/locale). To play nice in such an enviroment Python >> packages would have to install resource files outside of the python >> package and into the FHS specified directory structure. > > > Consider the example of a web page template containing embedded > Python code. Is that a data file containing code, or a code file > containing data? Where does the FHS say it goes? > > What if it's not embedded Python, but an embedded DSL interpreted by > the package it goes with? > > What if it's not a page template, but a precompiled SQL grammar? > (Such as was distributed with the "gadfly" package, many a year ago.) > > These are the kind of files I mean by "resources". If somebody wants > to support gettext or similar localization, then obviously they should > declare the files data -- or better yet, as part of an explicit > localization category. > > The whole point of "resources" is that it's a catch-all for static > data that's more convenient to treat as a standalone source file than > to inline as a huge triple-quoted constant in a .py file. ;-) Exactly: any dsitribution-packaer who tries to move such files out of the package due to some misunderstood FHS-driven theory about such files is just breaking the software to no purpose. - -1 to enabling such misuse, as distinct from "data" / "config" files which fall into other categories (documentation, example configs, etc.). Such files are not "resources" in any sensible use of the term. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCsTmsACgkQ+gerLs4ltQ4uBgCgnRRaQA0AjzaNOqPomSHOC7+s 19cAoMUl4FwpW6TDMAqSjG1Cj3bYx6bv =w8D1 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout 2.0.0a4 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2012 07:16 PM, Chris McDonough wrote: > On 11/19/2012 06:19 PM, Jim Fulton wrote: >> On Mon, Nov 19, 2012 at 6:00 PM, Alex Clark >> wrote: >>> Ugh, sorry. I wonder if we can get Richard Jones or Martin von >>> Löwis to modify PyPI such that "hiding" really means hiding >>> (CC'ing catalog-sig). >> >> That would be very bad. Old releases are often hidden. >> >>> I also wonder if that is the right thing to do. >> >> It's not. >> >>> Personally, I'd be OK with having to use find-links (or something >>> like it) to test the alpha e.g.: >>> >>> >>> $ pip install -f http://path/to/buildout.zip zc.buildout >> >> pip install >> https://github.com/downloads/buildout/buildout/zc.buildout-2.0.0a4.tar.gz >> >>> >> Actually what would be ideal (I think), if it were possible, is: >>> >>> - Upload sdist - Hide release - pip install zc.buildout installs >>> latest unhidden release - pip install zc.buildout==2.0.0a4 >>> installs 2.0.0a4. >>> >>> But that may be nonsensical… unless perhaps pip and easy_install >>> were to check a different index if/when an exact version spec is >>> given. :-/ >> >> What would be ideal would be for pip and easy_install to only >> install non-final releases if asked to. Or at least provide an >> option to prefer final releases. Buildout has had a prefer-final >> option for years. In an upcoming buildout 2 alpha, this will become >> the default. > > My $.02: PyPI consumers are not customers. They are collaborators. > They are collaborators who need to be paying active attention to what > they're doing if they choose to install random stuff from PyPI. > Doubly so if they're automating that installation. Triply so if the > automated installation of a system must not break because they'll lose > time or money or both as a result. > > There is no sense in ever making an alpha release if it's never going > to be installed by anybody. I agree that preferring final releases > should probably be the default for installer tools. However, even if > it's not, distribution creators shouldn't feel compelled to hold off > pushing an alpha release to PyPI for fear that someone might actually > use it. Amen. Let's not coddle folks who blindly install without checking, to the detriment of those who pay attention and will help find and fix bugs. Those who need the coddling should be paying somebody for the service. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCq5EIACgkQ+gerLs4ltQ687QCfSJiejVQS+76cdA/o7gLT7h/Y EkgAoL6EsKMfB9Yi96Sy4r/3Ovv0/yJu =Y24e -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] python setup.py develop and extras
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2012 06:47 AM, Chris Withers wrote: > On 05/11/2012 20:32, Daniel Holth wrote: >> Extras are just an alias for a set of dependencies. After you run >> setup.py develop on package, just "pip install >> package[docs,testing]" > > it's pyramid, and I want to do setup.py develop [docs,testing] FWIW, we lost this argument a while back and worked around it in Pyramid, zope.*, and repoze.*. the 'dev' and 'docs' aliases[1] do what you want: $ python setup.py dev docs []1 defined in 'setup.cfg' Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCZKSwACgkQ+gerLs4ltQ6R+wCg2qqDm8K2S55XKxAIr6wuP9Ux XFMAoLhldG170K9DS39siHCQLtpbTrck =aJs8 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [issue142] easy_install ignores 'headers' passed to setup()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2012 11:13 AM, Tres Seaver wrote: > > New submission from Tres Seaver : > > A bare distutils install of a package with 'headers' passed to > 'setup()' dispatches to 'install_headers', which copies the exported > header files into the system include path. > > 'easy_install' bypasses the distutils 'install()' when doing a normal > egg install, and does not re-implement the 'install_headers' dance. > > Furthermore, the 'bdist_egg' it creates, even though it contains the > header files, has no metadata which would allow the installer to > discover that they should be copied. Note that distribute has the same bug, which I reported here: https://bitbucket.org/tarek/distribute/issue/295 - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/7AqQACgkQ+gerLs4ltQ4/kwCfWEBYSY+dlEfD0b/QNxXnPNxA lPcAoIj0XsQCu2AbPuVWYLEGmWpfKL4Y =VNY3 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [issue142] easy_install ignores 'headers' passed to setup()
New submission from Tres Seaver : A bare distutils install of a package with 'headers' passed to 'setup()' dispatches to 'install_headers', which copies the exported header files into the system include path. 'easy_install' bypasses the distutils 'install()' when doing a normal egg install, and does not re-implement the 'install_headers' dance. Furthermore, the 'bdist_egg' it creates, even though it contains the header files, has no metadata which would allow the installer to discover that they should be copied. -- messages: 669 nosy: tseaver priority: bug status: unread title: easy_install ignores 'headers' passed to setup() ___ Setuptools tracker <http://bugs.python.org/setuptools/issue142> ___ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Adding Provides-Extra as an edit to PEP 345
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2012 10:32 AM, Daniel Holth wrote: >>> Add Provides-Extra: to PEP 345 and clarify Requires-Dist: name (1) >>> is the same as Requires-Dist: name (==1) > >> +1 > > Great. How do we get https://bitbucket.org/dholth/python-peps merged > into hg.python.org/peps/ ? Given that PEP 345 is already in 'Accepted' state, I'm not sure we can just merge it in. We might need to create a new PEP which extends PEP 345 and adds the feature (it likely needs to bump the 'Metadata-Version', too). Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/2+PQACgkQ+gerLs4ltQ57KwCfWR5W+gL0bgLOLOcyyOlXCI7e KTIAoLDLUTjNQjw9VA9Hx8R4rYbW5XqZ =pl62 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] using ZSQLMethods pypi package in zope 2.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2011 03:45 PM, Fernando Martins wrote: > Hi, > > I am using zope 2.9.9 and I was trying a migration to 2.13.8 which I > have installed with buildout. I am however struggling with this new > system, much more complex than the simple old Products system. > > The zope instance contains a Products folder where I have been able > to drop in a few packages (a subfolder in it, actually) from Pypi. > > However, ZSQLMethods contains the Shared subfolder which is a > dependency for the ZSQLMethods and I don't know where to put Shared > to make it work (it doesn't work under Products). > > Based on the buildout.cfg of ZSQLMethods, I did: > > [buildout] ... parts = ... zsql > > [zsql] recipe = zc.recipe.testrunner eggs = Products.ZSQLMethods > > However, running bin/buildout I got > > Error: Picked: Products.ZSQLMethods = 2.13.4 That error comes from having 'allow-picked-versions = false' in buildout.cfg -- you then need to supply an explicit version for every package. > I guess it should not be so difficult to install ZSQLMethods, but I > can't really figure it out. Suggestions? I think you want 'Products.ZSQLMethods' added to the 'eggs' value for your 'instance' section, so that it is on the sys.path when running the 'instance' script. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bZVgACgkQ+gerLs4ltQ7egACgsEvUswttXfNiW2HBKH3ethqV kbUAnRhB6F4zstK7FYnuNGIvMR0YO7UE =gKwx -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [buildout] [Errno 104] Connection reset by peer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2011 03:13 PM, Anton Panasenko wrote: > Hi guys, > > Who knows how to fix the problem: > > Download error: [Errno 104] Connection reset by peer -- Some packages may not > be found! This error indicates either that you have a transient network failure, or that your index server (likely pypi.python.org) is down. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3mOtIACgkQ+gerLs4ltQ6BpQCfQBUP1wtRYo8nNf0KHyoOHEVN dN8AnAyaefXWkvyjjtffZR+CrqhC+y81 =jJ77 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools + specifying project's version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2011 03:29 PM, Ruslan Spivak wrote: > Hi, > > In > http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version > there is a statement that 2.1-rc2 means you've already released 2.1 > and an example > > """ > >>>> parse_version('2.1-rc2') < parse_version('2.1') > False > > """ > > Running the example gives quite the opposite result (setuptools-0.6c11): > >>>> parse_version('2.1-rc2') < parse_version('2.1') > True > > and actually it turns out that a pre-release tag 2.1rc2 is equal to > the post-release tag 2.1-rc2 > > >>> parse_version('2.1-rc2') == parse_version('2.1rc2') > True > > Does anyone have any idea why that's the case or is it a bug? Likely a bug, due to the fact that nobody who could fix it uses post-release tags (I can't see the point, myself) -- just make another release already). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ITWkACgkQ+gerLs4ltQ4YogCfdXZw8noDKlQ/eRoBjz8Y1gO5 yN0Anj0seQNVfFw2iDGpmxpkrOpHIeRH =IIDM -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] dependencies, pip and non-PyPI-hosted packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/26/2011 12:02 PM, Ernesto Posse wrote: > On Sat, Apr 23, 2011 at 3:12 PM, Carl Meyer wrote: >> >> >> On 04/23/2011 02:00 PM, P.J. Eby wrote: >>> At 04:54 PM 4/22/2011 -0500, Carl Meyer wrote: >>>> No, it is calling the distribute setup. If you look at how your package >>>> is installed, you'll find it in an egg - that's a sure sign of >>>> setuptools/distribute. It's just that "python setup.py install" does not >>>> handle dependencies, even with setuptools/distribute. >>> >>> Uh, yes it does, actually. (At least with setuptools, it does; don't >>> know about distribute.) >> >> Erp. Yeah, you're right; just verified that it works fine with both >> setuptools and distribute. Dunno where I got that idea. >> >> Carl > > > I'm confused now. I have tried both with setuptools alone (using > ez_setup.py instead of distribute_setup.py) and distribute, and it > doesn't work with distribute alone for me: it doesn't install the > dependencies and gives me those warnings about 'install_requires' not > being recognized. > > Any ideas about what could be wrong? How are you invoking setup? Should be something like: from setuptools import setup setup(name='your.package', ... install_requires=['other.packaage'], ) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk23VXsACgkQ+gerLs4ltQ5O6gCfd8WzYUb6+bWlGvPC/ZUsfcHu NtIAn1pFAvWtvTV8Slap6Iopl2sT/5UD =Hi4F -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Need help with a usecase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/19/2011 03:46 AM, Reinout van Rees wrote: > On 18-04-11 16:32, Jim Fulton wrote: >>> My project (checked out from Git to be specific) comes with a >>>> Distribute-based setup.py, and I'd like to install it into an isolated >>>> Python environment. That is, the equivalent of running 'python >>>> setup.py.install' in my project directory, but into an isolated >>>> environment. >>>> I was hoping I could use Buildout for this. >> Your specific requirements is better matched by virtualenv. > > It *is* possible with buildout in case you want to experiment :-) > Put this in your buildout.cfg: > > [buildout] > develop = . > parts = scripts > > [scripts] > recipe = zc.recipe.egg > eggs = your-egg-name > > Grab a bootstrap.py, run it and run bin/buildout. > > > The one thing that, to me, still is a big advantage of buildout over > virtualenv in cases like this: you can just run the scripts in bin/* > as-is. You do not need to activate the virtualenv beforehand. You don't ever *need* to activate a virtualenv to run its scripts -- you just type 'bin/foo' from the VE root, or '/path/to/VE/bin/foo' from elsewhere. After using VE for years, I have literally never used activate, while using multiple VE's daily. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2t5yUACgkQ+gerLs4ltQ4KLACguvDEhCAlHdgLGajFZEqjlP+4 Cm8An3gTzHp7E9IkFA+aUpTl2P64n/2S =tHbE -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install doesn't work when there are multiple Content-Length headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2011 11:08 AM, Hoang Xuan Phu wrote: > Hi all, > > Just today I'm using easy_install to install mechanize and it is failing > with the error "ValueError: invalid literal for int() with base 10: '382727, > 382727'". By reading the source code and looking at the headers I see that > the server is returning 2 Content-Length headers (same value, 382727), which > is turned into '382727, 382727'. Fixing this should be very easy and I can > do it then submit a patch. I'm just wondering, as distutils seem to be in a > forking process, what's the best way to solve this? I reported this SF bug: http://sourceforge.net/apps/trac/sourceforge/ticket/18486 PJE has checked in my patch working around this bug. See issue 123: http://bugs.python.org/setuptools/issue123 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2QvEMACgkQ+gerLs4ltQ6M8ACdEjNaxg1w3M2jCc0JuqfAJeLa SG8AoLOfZdbIpvDwrgvidOk4g72i61zU =ZoDQ -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [issue124] Add support for installing test requirements to 'develop' command
New submission from Tres Seaver : The attached patch adds a '--with-test-requirements' / '-t' option to the 'develop' command: the rationale is that when developing a package, one should be able to run the tests without polluting the local checkout directory with the eggs specified by its 'tests_require': those eggs should be installed just as the other ones mandated by 'install_requires'. I would actually prefer to make this behavior the default, perhaps with a command-line-switch to disable it, but think that backward compatibility trumps that itch. -- assignedto: pje files: setuptools-0.6-develop-with_test_requirements.patch messages: 606 nosy: pje, tseaver priority: feature status: unread title: Add support for installing test requirements to 'develop' command Added file: http://bugs.python.org/setuptools/file76/setuptools-0.6-develop-with_test_requirements.patch ___ Setuptools tracker <http://bugs.python.org/setuptools/issue124> ___=== modified file 'EasyInstall.txt' --- EasyInstall.txt 2011-03-23 21:09:16 + +++ EasyInstall.txt 2011-03-28 14:42:42 + @@ -1218,6 +1218,8 @@ 0.6final + * Added ``--with-test-requirements`` flag to the 'develop' command. + * Fixed AttributeError under Python 2.3 when processing "HTTP authentication" URLs (i.e., ones with a ``user:password@host``). === modified file 'setuptools/command/develop.py' --- setuptools/command/develop.py 2008-01-19 02:55:03 + +++ setuptools/command/develop.py 2011-03-28 14:40:10 + @@ -13,6 +13,7 @@ user_options = easy_install.user_options + [ ("uninstall", "u", "Uninstall this source package"), ("egg-path=", None, "Set the path to be used in the .egg-link file"), +("with-test-requirements", "t", "Install test requirements"), ] boolean_options = easy_install.boolean_options + ['uninstall'] @@ -30,6 +31,7 @@ def initialize_options(self): self.uninstall = None self.egg_path = None +self.with_test_requirements = False easy_install.initialize_options(self) self.setup_path = None self.always_copy_from = '.' # always copy eggs installed in curdir @@ -100,6 +102,10 @@ # postprocess the installed distro, fixing up .pth, installing scripts, # and handling requirements self.process_distribution(None, self.dist, not self.no_deps) +# Install test requirements when developing. +if self.with_test_requirements and self.distribution.tests_require: +for tests_req in self.distribution.tests_require: +self.easy_install(tests_req) def uninstall_link(self): ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [issue123] [PATCH] Tolerate responses with multiple Content-Length headers
New submission from Tres Seaver : Some servers (e.g., wwwsearch.sourceforge.net) apparently send multiple 'Content-Length' headers, which causes setuptools to barf trying to convert a ', ' string to an integer. This bug breaks installing 'mechanize', which lists wwwsearch.sourceforge.net as its Download-URL, and therefore causes a bunch of Zope-related tests to fail (e.g., https://mail.zope.org/pipermail/cmf-tests/2011-March/014576.html ). The attached patch uses 'headers.getheaders('Content-Length')[0] to use only the first value found. -- assignedto: pje files: setuptools-multi_content_length.patch messages: 598 nosy: pje, tseaver priority: urgent status: unread title: [PATCH] Tolerate responses with multiple Content-Length headers Added file: http://bugs.python.org/setuptools/file75/setuptools-multi_content_length.patch ___ Setuptools tracker <http://bugs.python.org/setuptools/issue123> ___=== modified file 'setuptools/package_index.py' --- setuptools/package_index.py 2010-02-01 16:42:04 + +++ setuptools/package_index.py 2011-03-23 14:06:46 + @@ -550,7 +550,9 @@ bs = self.dl_blocksize size = -1 if "content-length" in headers: -size = int(headers["Content-Length"]) +# Some servers return multiple Content-Length headrers :( +content_length = headers.getheaders("Content-Length")[0] +size = int(content_length) self.reporthook(url, filename, blocknum, bs, size) tfp = open(filename,'wb') while True: ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig