Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
David Lyon wrote: > On Wed, 23 Sep 2009 09:49:16 +0200, "M.-A. Lemburg" wrote: > >> While it's a good idea to put up some form of meta-data >> into an index, I wonder why you are using setup.cfg >> for this. >> >> setup.cfg has traditionally been used to configure distutils, >> not to define meta-data. As such you wouldn't want to >> put such a configuration file up on PyPI. >> >> Wouldn't it be better use a new file for this (with the >> same syntax), e.g. metadata.cfg ?! This would then just >> contain the meta data that needs to be published. > > Forgive me if I answer this from being on the distutils-ml > but it is easy to answer and might save somebody else time. > > Currently, the metadata is stored within setup.py and the > biggest issue with that is maintaining the version number. > For instance, getting the same version number to go into the > documentation files, etc. So consensus was that keeping that > information in setup.py is somewhat cumbersome and putting > it somewhere else would be better. Tarek suggested setup.cfg > and it seems to make the most sense. So the idea is to make the setup() parameters settable via the setup.cfg as well ?! (+1 on that) Or are you suggesting that the setup.cfg file be the *only* place to set the version number ? (I'd be -1 on that, because you often need to determine the version number dynamically, e.g. when doing snapshot releases) In my experience, it's usually better to place all the setup() keyword parameters into a separate module which can then be loaded by other tools as well - see e.g. egenix-mx-base for what I mean: http://www.egenix.com/products/python/mxBase/#Download The setup.py module itself then just loads this configuration module and uses the values from it to fire off distutils. > By moving the metadata values into a configParser format file, > it would mean that external scripts could more easily > access/update the version number as required. > > Of course, setup.cfg wouldn't get uploaded. Nobody would > want to do that. > > But distutils would create the .PKG_INFO file and metadata > from configuration, and not from hardcoded string values > within setup.py as it does now. I lost you there... if you have the setup.py file available, where is the problem in running "python setup.py somecommand" to extract the metadata into some other file ? As far as I understood Tarek's summary, the idea was to have a separate file with just the metadata to upload to PyPI in order to have tools working on the PyPI index extract that metadata without having to download the whole installation package. That's a very good idea. The only problem I saw was the name of the file that Tarek chose and whether or not he was actually referring to the setup.cfg used for configuring distutils or not. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 24 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [OT] cutting the cc list
P.J. Eby telecommunity.com> writes: > > I doubt that it was intentional on Tarek's part (checking the thread > shows that Antoine's the one who first cut the cc: list), but the > fact remains that I hadn't seen it when I sent my > message. Just FYI, there are two reasons that I cut the CC list: - I usually do it deliberately, when replying from e-mail, because I don't want people to get duplicates, nor to get an e-mail not coming from the list which might then not match with their own ML filters (based on whatever headers the ML machine adds to e-mails) - In the python-dev case, I reply through gmane, and gmane doesn't do any CC, it posts only to the list cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Thu, 24 Sep 2009 at 12:07, Nick Coghlan wrote: Mark Dickinson wrote: On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote: We are going to start contributing tests back real soon now. I'm not sure that these are the best tests to contribute as they require a version of Python to compare against rather than being nice and stand alone. But I'm sure we have other tests which cover this as well just not as exhaustively. We could also possibly check in the baseline file and then CPython could compare it's self to previous versions but it'd probably be a pretty big file - so it probably shouldn't be included in the standard install in the tests directory. How big is big? For comparison, CPython's Lib/test/decimaltestdata directory alone is already over 4Mb, so maybe size isn't an issue? For big test files, there's also the option of including download logic in the test to go retrieve it from a known URL (I believe we already do that for some of the codec tests). We do. There's even support code in test.support for handling such downloads relatively cleanly (and cleaning up afterward, though that last was only added recently). --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7 / buildbots / testing
Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a écrit : > > Depends on where the machines are. There are good tools do check all > automatically. Nagios is one. > > Anyway, this would suite my work schedule for the next 12 months. > > Do we already have the machines? or do they need to be acquired? I have (root) access to a powerful x86-64 Debian machine that I might give you non-root access to, if it's enough. I'll have to ask the owner of the machine, however. Tell me if that can be useful. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7 / buildbots / testing
On Thu, 24 Sep 2009 at 13:49, Antoine Pitrou wrote: Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a ??crit??: Depends on where the machines are. There are good tools do check all automatically. Nagios is one. Anyway, this would suite my work schedule for the next 12 months. Do we already have the machines? or do they need to be acquired? I have (root) access to a powerful x86-64 Debian machine that I might give you non-root access to, if it's enough. I'll have to ask the owner of the machine, however. Tell me if that can be useful. I've been a sysadmin for years (among other things). If Jean-Paul's suggestion of forming a small team to manage this is followed, I volunteer to be part of that team. And if Snakebite isn't enough I have a well-connected platform I could run Linux buildbots on in vserver virthosts, and a less-well-connected platform that could run KVM based stuff. --David (R. David Murray)___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7 / buildbots / testing
R. David Murray bitdance.com> writes: > > And if Snakebite isn't enough I > have a well-connected platform I could run Linux buildbots on in > vserver virthosts, and a less-well-connected platform that could run > KVM based stuff. I suppose Snakebite will be enough, but only once it is ready :) We still need some buildbots (or any equivalent) in the meantime... Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7 / buildbots / testing
> Do we already have the machines? or do they need to be acquired? Yes, the machines are all there, see http://www.python.org/dev/buildbot/all/ Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7
>> Additionally, I'm very apprehensive about doing any kind of release >> without the buildbots running. Does anyone know when they might be up? When I (or somebody else) contacts all the slave operators and asks them to restart the buildbot slaves. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7
On 24 Sep, 11:27 pm, [email protected] wrote: Additionally, I'm very apprehensive about doing any kind of release without the buildbots running. Does anyone know when they might be up? When I (or somebody else) contacts all the slave operators and asks them to restart the buildbot slaves. Does this mean you're taking responsibility for this task? Or are you looking for a volunteer? Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thinking about 2.7
>> When I (or somebody else) contacts all the slave operators and asks them >> to restart the buildbot slaves. > > Does this mean you're taking responsibility for this task? Or are you > looking for a volunteer? I had been running this buildbot installation ever since I created it, and will happily continue to take responsibility for it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
