http://blog.gmane.org/gmane.comp.python.catalog hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.python.catalog/5661 <pre>Catalog-sig is now dead, but I felt it made sense to tie off this thread by mentioning our new solution.: =========================== Defend Against Fruit is focused on providing a pragmatic, continuous deployment style build system for Python. Current Python build systems do not properly account for the needs of effective continuous deployment. This package extends the Python tooling to add the missing pieces, including integration with Artifactory. With an eye to agile development principles and fast-feedback, we want a build system which satisfies the following goals: * Every SCM change-set committed should result in a potentially shippable release candidate. * When a defect is introduced, we want to immediately detect and isolate the offending SCM change-set. This is true even if the defect was introduced into a library we depend upon. * Library management should be so easy as to never impede code changes, even in multi-component architecture. More details available at: http://teamfruit.github.io/defend_against_fruit/ &lt;http://teamfruit.github.io/defend_against_fruit/&gt; License: Apache Public License v2 Authors: James Carpenter jcarpenter621 at yahoo.com LinkedIn: http://www.linkedin.com/in/jamescarpenter1 &lt;http://www.linkedin.com/in/jamescarpenter1&gt; Matthew Tardiff mattrix at gmail.com LinkedIn: http://www.linkedin.com/in/matthewtardiff &lt;http://www.linkedin.com/in/matthewtardiff&gt; On Thu, Feb 21, 2013 at 5:21 PM, James Carpenter &lt;nawkboy&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> James Carpenter 2013-05-18T21:31:47 http://permalink.gmane.org/gmane.comp.python.catalog/5660 <pre>Please direct all followups / CCs to distutils-sig. Thankyou, Richard _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Richard Jones 2013-04-01T06:41:10 http://permalink.gmane.org/gmane.comp.python.catalog/5659 <pre> It's the install_eggs() method of setuptools.commands.easy_install.easy_install. You won't really be able to use it, it just looks for a setup.py after *unpacking* the archive. It also doesn't look for a PKG-INFO; PyPI does that. (And I only know that because it was relevant to the uploadability of eggs at one time.) </pre> PJ Eby 2013-04-01T04:59:55 http://permalink.gmane.org/gmane.comp.python.catalog/5658 <pre> The closest equivalent is PEP 376's "INSTALLER" file, but that only tells you which installer was used to add the distribution, rather than where that installer retrieved it from. An "ORIGIN" entry in the installation database could be an interesting future addition. Cheers, Nick. </pre> Nick Coghlan 2013-04-01T01:36:19 http://permalink.gmane.org/gmane.comp.python.catalog/5657 <pre>Do you have a module/function/line number in easy_install I should use? I'm sure I can dig it out myself but it sounds like you might just be able to put your finger on it in only a minute or two. Same question for a pre-existing utility function for reading a requirements file. I'm guessing there is one burried down in the PIP code, but I haven't looked yet. A third more interesting question, is whether there is any way to determine the origin of an installed package. I am building up a build-info to push into Artifactory and it takes a "type" if available when listing dependencies of a build. In Java/Maven land a typical type would be jar, war, pom, etc. My current understanding is this is a non-sense question, since once a Python module is installed it looks the same regardless of whether it came from an sdist, wheel, etc. In case your wondering, I am building a set of utilities to support continuous deployment within Python. I am using Artifactory as my repository manager (think internal PyPI server). I hope to publish these utilities externally when I get done in a few weeks. On Fri, Mar 29, 2013 at 1:54 PM, PJ Eby &lt;pje&lt; at &gt;telecommunity.com&gt; wrote: _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> James Carpenter 2013-03-31T22:13:46 http://permalink.gmane.org/gmane.comp.python.catalog/5656 <pre>I've set the wheels in motion. I just need a little help from the pydotorg volunteers (and some hits from the mailman cluebat). Richard On 30 March 2013 06:43, Donald Stufft &lt;donald&lt; at &gt;stufft.io&gt; wrote: _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Richard Jones 2013-03-30T22:20:15 http://permalink.gmane.org/gmane.comp.python.catalog/5655 <pre>Hi all, We're about to merge the catalog-sig and distutils-sig by just removing the catalog-sig mailing list. If you wish to remain in the discussions regarding Python package cataloging then please subscribe to the distutils SIG. The catalog SIG archives will remain, but the mailing list will be deleted and the SIG will be retired. There's no real timeframe but it will be happening imminently. Richard _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Richard Jones 2013-03-30T22:16:38 http://permalink.gmane.org/gmane.comp.python.catalog/5654 <pre> On Mar 29, 2013, at 3:40 PM, Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; wrote: Sounds good to me, whoever please to doing the needful. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Donald Stufft 2013-03-29T19:43:06 http://permalink.gmane.org/gmane.comp.python.catalog/5652 <pre> I'm not sure why you think that. The only kinds of archives whose file types are ambiguous from the name, are sdist, bdist_dumb, and random raw source dumps. Everything else has a unique extension like .egg, .exe, .msi, rpm, etc. If you have a .zip, .tar.gz, .tgz, or some other archive name, you can find out if it's an sdist by inspecting its contents as I described. And if it's not an sdist, you can usually tell if it's a raw source dump by checking for a setup.py in the archive root or a depth-1 subdirectory off the root. (That's what easy_install does, anyway, when it's given an archive it doesn't know what to do with.) </pre> PJ Eby 2013-03-29T18:54:22 http://permalink.gmane.org/gmane.comp.python.catalog/5651 <pre> Whoever has the power to do this, do it please. Richard </pre> Richard Jones 2013-03-29T09:47:48 http://permalink.gmane.org/gmane.comp.python.catalog/5650 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/2013 05:57 PM, Donald Stufft wrote: If we leave the main list the 'distutils-sig', and just announce that 'catalog-sig' is retired, folks who want to follow the new list just switch over. All the archives (mailman / gmane / etc.) stay valid, but the list goes into moderated mode. Creating a third list and retiring both the existing ones is extra hassle for no value, aside for a "cleanliness" issue on its name. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver&lt; at &gt;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/ iEYEARECAAYFAlFVDmoACgkQ+gerLs4ltQ4yDQCfZCEUpSTIhQKNNDilIYIRc6Jj Fu0AoM6RKaflwbeek0VFGsX1USIzUhlC =gWkJ -----END PGP SIGNATURE----- </pre> Tres Seaver 2013-03-29T03:45:52 http://permalink.gmane.org/gmane.comp.python.catalog/5649 <pre> Without yet reading the whole thread, I'll just mention that it's probably easier to just retire one or the other mailing lists and divert all discussion to the other one. Of course, the archives for the retired list would be retained for historical purposes. In fact, sigs are *supposed* to be periodically reviewed for renewal or retirement, though I think practically speaking we haven't done that in a very long time. If there's consensus on what you want to do, please contact postmaster&lt; at &gt; and let them know. Let's say you just want to retire catalog-sig: we can set up forwards to distutils-sig and let the former be an "acceptable alias" to the latter so postings will be accepted when addressed to either. Of course, folks on the defunct list should manually subscribe to the good list (i.e. opt-in). -Barry _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Barry Warsaw 2013-03-29T02:59:11 http://permalink.gmane.org/gmane.comp.python.catalog/5647 <pre> On Mar 28, 2013, at 7:28 PM, PJ Eby &lt;pje&lt; at &gt;telecommunity.com&gt; wrote: A requirement for a SIG is also that it has a clear goal and a start and end date. distutils-sig's goal is the distutils module. And the "end date" requirements seems to be completely ignored anymore so arguing strict adherence to the rules seems to be a wash. I suggested packaging-sig because discussion jumps back and forth between distutils-sig and catalog-sig and neither name nor stated goal really reflected what the sig was actually about which was packaging in python in general. I also suggested packaging because it matched the other current sigs which are generic topics and not about a single module. But whatever, I hate the pointless duplication and just want to kill the overlap. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Donald Stufft 2013-03-28T23:45:55 http://permalink.gmane.org/gmane.comp.python.catalog/5646 <pre> I'm not arguing about the *name*. I just don't see the point in making everybody subscribe to a new list and change their mail filters (and update every book and webpage out there that mentions the distutils-sig), because a few people want to *change* the name -- a change that AFAICT doesn't actually provide any tangible benefit to anybody whatsoever. Because it's not up to just the person with the keys. Neither SIG is a mere mailing list, it's a Python special interest group, and SIGs have their own formation and termination processes. In particular, if you're going to start a new SIG, one of the requirements to be met is "in particular, no other SIG nor the general Python newsgroup is already more suitable" (per the Python SIG Creation Guidelines). It's hard to argue that distutils-sig isn't already more suitable than whatever is being proposed to take its place. </pre> PJ Eby 2013-03-28T23:28:14 http://permalink.gmane.org/gmane.comp.python.catalog/5645 <pre>On 2013-03-28 21:57:11 +0000, Donald Stufft said: FWIW: I am a GMANE-sipper and I'm willing to rejoin a new packaging-sig list (as well as register the new list with GMANE if no one else does). Seems to me another viable option is to simply turn off catalog-sig and distutils-sig (while preserving the archives forever, of course) and just start chatting on packaging-sig. Send an email to both lists "Last post, please join packaging-sig" and you are done. </pre> Alex Clark 2013-03-28T23:01:45 http://permalink.gmane.org/gmane.comp.python.catalog/5644 <pre> On Mar 28, 2013, at 5:42 PM, Tres Seaver &lt;tseaver&lt; at &gt;palladion.com&gt; wrote: This problem is inherent no matter what name is picked. GMane will need updated and some messages will need sent to tell people about the new name. No matter what at least one name isn't going to be used anymore. It's not that big of a deal. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Donald Stufft 2013-03-28T21:57:11 http://permalink.gmane.org/gmane.comp.python.catalog/5642 <pre>I think I'm the only one on the list who probably would have objected but I'm on both now so whatever :-) Richard On 29 March 2013 07:32, PJ Eby &lt;pje&lt; at &gt;telecommunity.com&gt; wrote: </pre> Richard Jones 2013-03-28T21:42:06 http://permalink.gmane.org/gmane.comp.python.catalog/5641 <pre>C'mon, folks, we're arguing about a name. That's about as close to literal bikeshedding as we could get. How about we just let whoever has the keys make the change in whatever way's easiest and most logical for them? Jacob </pre> Jacob Kaplan-Moss 2013-03-28T21:15:56 http://permalink.gmane.org/gmane.comp.python.catalog/5640 <pre> An sdist always has a single subdirectory in the archive's root directory, named for the package+version, and containing a PKG-INFO and setup.py (plus a bunch of other stuff). A bdist_dumb will not have such a subdirectory in the archive root; instead it will have one or more directories like /usr, /opt, /Program Files. Other bdist formats? Hard to say. </pre> PJ Eby 2013-03-28T20:36:22 http://permalink.gmane.org/gmane.comp.python.catalog/5639 <pre> On Mar 28, 2013, at 4:04 PM, holger krekel &lt;holger&lt; at &gt;merlinux.eu&gt; wrote: sounds good to me. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> Donald Stufft 2013-03-28T20:32:16 http://permalink.gmane.org/gmane.comp.python.catalog/5637 <pre>Is there an easy way to programmatically tell if an archive (tar.gz, zip, etc.) in the dist directory is a binary or sdist? I would like to post-process the contents of a dist directory and classify each build artifact there (egg, sdist, bdist, etc.). Currently the only approach I know of is to have my own command that is run along with the relevant build command. For example: python setup.py sdist be_funky or: python setup.py sdist bdist bdist_egg be_funky Using this approach the tuples in self.distribution.dist_files provide the command, python version and file created. Unfortunately this solution is slightly more complicated in my use case than simply having an easy way to classify each build artifact and extract it's pkg-info. _______________________________________________ Catalog-SIG mailing list Catalog-SIG&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/catalog-sig </pre> James Carpenter 2013-03-28T19:57:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.catalog