[Distutils] [RFC] PEP 345 and PEP 386 updates
Hi, PEP 345 is the PEP for the new metadata format, replacing PEP 314. I have upgraded it, using Tres's work from last year, and the next step is to add the context marker presented in PEP 390. I have also updated PEP 386 to link it to PEP 345. = PEP 345 : Summary of Differences From PEP 314 = * Metadata-Version is now 1.2. * Added fields: - Maintainer - Maintainer-email - Requires-Python - Requires-External - Requires-Dist - Provides-Dist - Obsoletes-Dist * Deprecated fields: - Requires (in favor of Requires-Dist) - Provides (in favor of Provides-Dist) - Obsoletes (in favor of Obsoletes-Dist) Please comment! Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the virtualenv-distribute mess
Tres Seaver wrote: Huh? Why? I just don't buy this. We've effectively had a bdfl pronouncement that setuptools is dead. distribute 0.6 *is* now the "live supported setuptools" so any project that relies on the package called "setuptools" should now be using the "distribute" distribution... Are you being wilfully ignorant here, Chris? he BDFL doesn't "control" setuptools, because it is a *third party package*. Why is why an area as fundamentally important as this should be in the stdlib and not at the whim of third party developers ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
Toshio Kuratomi wrote: True... but because of that people are able to specify setuptools in setup.py and it will work with either distribute or setuptools. If you mean in the "install_requires" or "setup_requires" parameters to setuptools setup method, then I'm yet to see a use case where this is required... > you're getting at that if people didn't specify setuptools in setup.py, > distribute-0.6 could install without using the setuptools name? Without faking the setuptools distribution, yes. > I don't > think that works since you still need to take over the setuptools module package != module != distribution. setuptools and distribute are both distributions that provide a setuptools package. However, requirements are specified in terms of distributions, which is why people specifying setuptools as a requirement causes problems. As I've said several times now, I just can't see any point in doing that... will someone please enlighten me as to why people feel the need to specify "setuptools" in "install_requires" or "setup_requires" when the code that parses those requirements can't execute unless a package called setuptools is present already? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
Hanno Schlichting wrote: On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver wrote: Why? Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute. To quote Toshio Kuratomi: It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py. So apparently there are others who read and value this information. I'd put money on there being no packaging system that parses requirements sections out of a setup.py other that setuptools/distribute... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
Chris Withers a écrit : > Hanno Schlichting wrote: >> On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver >> wrote: >>> Why? Nobody will check / enforce / understand what 'install_requires' >>> even means except setuptools / distribute. >> >> To quote Toshio Kuratomi: >>> It's nice for people creating system packages when you specify all of >>> the >>> packages that your runtime depends on in setup.py. >> >> So apparently there are others who read and value this information. > > I'd put money on there being no packaging system that parses > requirements sections out of a setup.py other that setuptools/distribute... buildout, zc.recipe.egg and others recipes flavors do. > > Chris > -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
2009/10/20 kiorky : > buildout, zc.recipe.egg and others recipes flavors do. But they use setuptools to do so, I hope? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
On Tue, Oct 20, 2009 at 7:05 AM, kiorky wrote: > buildout, zc.recipe.egg and others recipes flavors do. These tools don't parse setup.py; they execute setup.py in a constrained context (possibly a separate process; don't recall offhand) in order to collect the metadata. Parsing the setup.py would be insane. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
Tarek Ziadé wrote: > Hi, > > PEP 345 is the PEP for the new metadata format, replacing PEP 314. I > have upgraded it, using Tres's work from last year, and the next step > is to add the context marker presented in PEP 390. > > I have also updated PEP 386 to link it to PEP 345. > > = PEP 345 : Summary of Differences From PEP 314 = > > * Metadata-Version is now 1.2. > > * Added fields: > > - Maintainer > - Maintainer-email > - Requires-Python > - Requires-External > - Requires-Dist > - Provides-Dist > - Obsoletes-Dist > > * Deprecated fields: > > - Requires (in favor of Requires-Dist) > - Provides (in favor of Provides-Dist) > - Obsoletes (in favor of Obsoletes-Dist) Where's the benefit of renaming the above three fields ? After all, the meta-data format is a distutils specific format, so the extra "-Dist" qualifier appears unnecessary. I'd also remove the "Requires-" from "Requires-Python" and simply use "Python" as field name. The intent should be clear, e.g. for Python 2 packages that need at least 2.6: Python: >2.6, <3.0 I'd also like to suggest the addition of conditional field values as already discussed in private mail. This would allow defining requirements based on the target platform and use the same micro-language as suggested in PEP 390. Here's a sketch (following Python's inline if syntax and the example from PEP 390): requires: pywin32; if sys_platform == 'win32' requires: bar (>1.0); if sys_platform == 'win32' requires: foo; if platform_machine == 'i386' requires: bar; if python_version == '2.4' or python_version == '2.5' requires: baz; if 'linux' in sys_platform Each of the listed requires field entries only applies if the condition matches the target platform. The micro-language should provide a limited number of variables to use on the conditions: python_version = sys.version sys_platform = sys.platform os_name = os.name platform_machine = platform.machine() platform_version = platform.version() and possibly more. The same notation could also be used in setup() keyword parameters for the meta-data fields, e.g. setup(..., requires=["pywin32; if sys_platform == 'win32'"], ...) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 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/ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
For minitage.recipe.*, yes it uses setuptools API. They also redo on the fly the python sdist dance in some case and reload the distribution using also setuptools API. And in the "patch" use case [1], they also patch the PKG-INFO file with a generated version info and use setuptools API to reload the distribution. For what i know of others API, they don't mess directly with setup.py either. [1] - http://pypi.python.org/pypi/minitage.recipe.egg#patches Lennart Regebro a écrit : > 2009/10/20 kiorky : >> buildout, zc.recipe.egg and others recipes flavors do. > > But they use setuptools to do so, I hope? > -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata
Ronald Oussoren wrote: 2) Notice that simplejson gets installed and is a useful module, then use that in your own scripts At this point, you specify your scripts' dependencies on simplejson. Look at it another way: You follow you process above, but after step 2, your development machine suffers a disk failure so you start from scratch on a new machine. Are you surprised at this point that simplejson isn't installed when you set things up again, even though by this point you've decided not to use TurboGears? Code should always specify their dependencies, not doing so will cause you problems down the line... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 390 - new format from setup.cfg
Ian Bicking wrote:
long_desc = open(os.path.join(os.path.dirname(__file__), 'docs',
'index.txt')).read()
long_desc = long_desc.split('..contents::', 1)[1].strip()
setup(..., long_description=long_desc)
Yes, and yet everytime I ask for the ability specify long description as
a file path relative to the pacakge, I get shouted at ;-)
(Come to think of it, I'm not actually sure what we're accomplishing
with this declarative metadata; "setup.py --name" is too minimal, but
some new "setup.py metadata" command that dumps everything isn't hard
to imagine; what are the *real* advantages of this new proposal? If I
have to use a build process to build my setup.cfg, then absolutely
nothing will be accomplished. And is the complexity all just because
sometimes people need to use version-specific requirements?)
To wind right back, the original requirement for static metadata was so
that it could be published on PyPI and package management tools could
parse requirements without having to download the package and execute an
untrusted .py file.
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386
Tarek Ziadé wrote: Then, the day PEP 386 is accepted, we turn "python_version" into a Version() object and we introduce '>', '<' and al. What's stopping PEP 386 being accepted? Seems like it'd be a good idea to get it out of the way first... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386
On Tue, Oct 20, 2009 at 2:30 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Then, the day PEP 386 is accepted, we turn "python_version" into a >> Version() >> object and we introduce '>', '<' and al. > > What's stopping PEP 386 being accepted? > Seems like it'd be a good idea to get it out of the way first... The last round (last summer) was not in favor of having post/dev markers in the version scheme (these are required by some developers), so PEP 345 and PEP 386 where sleeping a bit. But I have added a note in PEP 386 saying that following this scheme was not mandatory (as PEP 345 mentions), and these markers don't hurt people that want lighter schemes, so.. So I've sent a new mail to RFC PEP 345 + PEP 386, and I am cc'ing Paul, who was IIRC, not in favor of the PEP as it stands now. Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Alternate static metadata PEP submission...
David Lyon wrote: What we actually need, and I am building, is a setup.py script that is going to be a 'trimmed' version of distutils that includes all neccessary package/application installation code to do the install from the setup.info file. Be very aware of the problems of proliferating boilerplate code (buildout has already suffered this): - old versions will have to work forever - bug fixes are *very* hard to do I would like my setup.py to look like: from xxx import setup setup() ...and have all the code be in xxx. If xxx is a separately available package for python<2.7, then fine. I would prefer to see "hard logic" in setup.py where there is a good programming language to support it any everything else in setup.cfg (don't like .info, sorry ;-) ). My hunch is that for 95% of packages, setup.py will be nothing more than the above... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386
Tarek Ziadé wrote: On Tue, Oct 20, 2009 at 2:30 PM, Chris Withers wrote: Tarek Ziadé wrote: Then, the day PEP 386 is accepted, we turn "python_version" into a Version() object and we introduce '>', '<' and al. What's stopping PEP 386 being accepted? Seems like it'd be a good idea to get it out of the way first... The last round (last summer) was not in favor of having post/dev markers in the version scheme (these are required by some developers), so PEP 345 and PEP 386 where sleeping a bit. I'm sure I can't be the only person suffering from PEP overload when it comes to packaging. Any chance we could at least get dev/post markers in PEP386 and get it done and out of the way? I have a feeling that PEP345 and PEP390 along with David's alternative proposal are all related in such a way that the best thing ot do is bottom out the latter two first, but they all seem to depend (whether or not they want to admit it ;-) ) on PEP 386... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386
On Tue, Oct 20, 2009 at 2:56 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> On Tue, Oct 20, 2009 at 2:30 PM, Chris Withers >> wrote: >>> >>> Tarek Ziadé wrote: Then, the day PEP 386 is accepted, we turn "python_version" into a Version() object and we introduce '>', '<' and al. >>> >>> What's stopping PEP 386 being accepted? >>> Seems like it'd be a good idea to get it out of the way first... >> >> The last round (last summer) was not in favor of having post/dev >> markers in the version scheme >> (these are required by some developers), so PEP 345 and PEP 386 where >> sleeping a bit. > > I'm sure I can't be the only person suffering from PEP overload when it > comes to packaging. > Any chance we could at least get dev/post markers in > PEP386 and get it done and out of the way? > > I have a feeling that PEP345 and PEP390 along with David's alternative > proposal are all related in such a way that the best thing ot do is bottom > out the latter two first, but they all seem to depend (whether or not they > want to admit it ;-) ) on PEP 386... > Agreed. And every piece of puzzle is starting to emerge. As Marc-André said, PEP 390 is less important and could be done in distutils even without PEP, as long as we add the markers in PEP 345, (meaning we accept 386). And while David's alternative proposal competes with PEP 390 I don't see that as a problem: PEP 390 proposes to build the metadata using options in setup.cfg, whereas David's proposal proposes another system, but at the end, they all end up in a PKG-INFO. Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386
On Oct 20, 2009, at 8:56 AM, Chris Withers wrote: I'm sure I can't be the only person suffering from PEP overload when it comes to packaging. +1 on PEP overload Any chance we could at least get dev/post markers in PEP386 and get it done and out of the way? +1 on getting the versioning number scheme nailed down. The reference implementation looks pretty good from a quick review and the tests, while not insanely exhaustive, seem to cover everything that would come up in practice. If anyone disagrees with that last assessment, how about providing a test case? I have a feeling that PEP345 and PEP390 along with David's alternative proposal are all related in such a way that the best thing ot do is bottom out the latter two first I'm not sure anymore what "bottom out the latter two first" means, but getting 386 out of the way would certainly make everything else easier. S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg wrote: > Where's the benefit of renaming the above three fields ? I don't see any benefit here either; if we want to add fields for Python package or anything else, new (more explicit) field names can be added, without ever requiring these to be changed. As much as having more explicit names would be nice, it's not worth the disruption caused by deprecation cycles, or the accompanying confusion. These sorts of changes have very long uptake, while the clarity benefit is close to non-existent. > I'd also remove the "Requires-" from "Requires-Python" and > simply use "Python" as field name. +0 > The micro-language should provide a limited number of > variables to use on the conditions: > > python_version = sys.version > sys_platform = sys.platform If we adopt such a micro-language (I'm reserving judgment until I've had more time to read the relevant PEPs carefully), I'd rather see the names match what's in the Python runtime more closely, probably only avoiding the call syntax. This would make the examples: requires: pywin32; if sys.platform == 'win32' requires: bar (>1.0); if sys.platform == 'win32' requires: foo; if platform.machine == 'i386' requires: bar; if sys.version == '2.4' or sys.version == '2.5' requires: baz; if 'linux' in sys.platform > The same notation could also be used in setup() keyword > parameters for the meta-data fields, e.g. Whatever notation is adopted should be used consistently. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
Fred Drake wrote: Parsing the setup.py would be insane. As is specifying the setuptools distribution as a requirement when you're already using it... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers wrote: > As is specifying the setuptools distribution as a requirement when you're > already using it... I don't use setuptools at runtime unless something requires it. Having it available at install time and run time are two different things, and should remain so. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 345
Tarek Ziadé wrote: Agreed. And every piece of puzzle is starting to emerge. As Marc-André said, PEP 390 is less important and could be done in distutils even without PEP, as long as we add the markers in PEP 345, (meaning we accept 386). What markers are you referring to? A quick scan of http://www.python.org/dev/peps/pep-0345/ shows no sign of any of the contentious bits of PEP390. What am I missing? (other than that 386 should be accepted and implemented asap...) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
Fred Drake wrote: On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers wrote: As is specifying the setuptools distribution as a requirement when you're already using it... I don't use setuptools at runtime unless something requires it. Having it available at install time and run time are two different things, and should remain so. All I'm saying is that packages shouldn't express a dependency on setuptools if setuptools is required even before that expression can be parsed. I'm not talking about install or run time... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 345
On Tue, Oct 20, 2009 at 3:47 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Agreed. And every piece of puzzle is starting to emerge. >> >> As Marc-André said, PEP 390 is less important and could be done in >> distutils even without PEP, >> as long as we add the markers in PEP 345, (meaning we accept 386). > > What markers are you referring to? > > A quick scan of http://www.python.org/dev/peps/pep-0345/ shows no sign of > any of the contentious bits of PEP390. What am I missing? That's the part I have not added yet. Markers are the "sys_platform == 'win32" things discussed in PEP 390. See the other thread (RFC: PEP 345...) > (other than that 386 should be accepted and implemented asap...) Its implemented, we just need a consensus no consensus would mean that if a minority that have enough supporters objects the PEP, and provide an alernative, we would have another round. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 345
On Oct 20, 2009, at 9:53 AM, Tarek Ziadé wrote: (other than that 386 should be accepted and implemented asap...) Its implemented, we just need a consensus +1, ship it! S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] supporting multiple versions of one package in one environment is insane
[moving to disutils-sig where this belongs] Toshio Kuratomi wrote: where type of problem == sandboxed environment, sure. How do you solve the problem for system packagers? What's to stop a system packager either just running the buildout on install, or running the buildout at package build time and then just dropping the resulting environment wherever they want to install applications? Such a package would only be dependent on the right python version at runtime... If buildout creates sandboxed environments like virtualenv then everything here applies: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries That's fine, buildout can use a shared eggs directory (it's how I run it by default, to minimise the amount of downloading that goes on). In that case, there would be no duplication of packages, the "installed app" would just pick from a folder full of eggs that you could put wherever your OS wants them... In short, have multiple versions of a python package on the python path at the same time is insane ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools 0.6c11 released
Oops! - Due to a couple of last-minute issues with the 0.6c10 release, I've released an 0.6c11 update at: http://pypi.python.org/setuptools/ It fixes an error when running the "sdist" command on a package with no README, and includes the 64-bit Windows fix that was promised in 0.6c10 but wasn't actually checked in to SVN. You can install the updated version using easy_install (or pip!), by asking for setuptools==0.6c11. The Fine Print -- (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any bugs to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Chris Withers wrote: [following up on distutils-sig] Michael Foord wrote: Many Windows users would be quite happy if the standard mechanism for installing non-source distributions on Windows was via the wininst binaries. ...and many users may not be ;-) I know I'd be extremely unhappy if that were the case as I routines use multiple versions of packages with multiple versions of python on one machine... I wonder if it is going to be possible to make this compatible with the upcoming distutils package management 'stuff' (querying for installed packages, uninstallation etc) since installation/uninstallation goes through the Windows system package management feature. I guess it would be eminently possible but require some reasonably high level Windows-fu to do. I wouldn't have a problem if integrating with the windows package manager was an optional extra, but I think it's one of many types of package management that need to be worried about, so might be easier to get the others working and let anyone who wants anything beyond a pure-python packaging system that works across platforms, regardless of whether binary extensions are needed, do the work themselves... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, Oct 20, 2009 at 01:37:48PM +0200, M.-A. Lemburg wrote: [...] > > * Added fields: [...] > > - Requires-Dist > > - Provides-Dist > > - Obsoletes-Dist > > > > * Deprecated fields: > > > > - Requires (in favor of Requires-Dist) > > - Provides (in favor of Provides-Dist) > > - Obsoletes (in favor of Obsoletes-Dist) > > Where's the benefit of renaming the above three fields ? > > After all, the meta-data format is a distutils specific format, > so the extra "-Dist" qualifier appears unnecessary. In PEP 314 the "Requires" field is meant to contain module or packages names. Now OTOH it seems people are more interested in the distribution names. Making this change explicit is a good thing I reckon. (There's a whole other discussion about how it would be easier to provide an alternative implementation if it was done on module/package name instead of distribution name, but I haven't got enough experience with that so am happy to go with what actually seems to be used now.) Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 345
Tarek Ziadé wrote: A quick scan of http://www.python.org/dev/peps/pep-0345/ shows no sign of any of the contentious bits of PEP390. What am I missing? That's the part I have not added yet. Markers are the "sys_platform == 'win32" things discussed in PEP 390. But PEP345 is about the metadata that appears in the installed package, no? What use is it having conditionals in there at all? (other than that 386 should be accepted and implemented asap...) Its implemented, we just need a consensus no consensus would mean that if a minority that have enough supporters objects the PEP, and provide an alernative, we would have another round. What are the current sticking points? I do remember some discussions surrounding this but didn't see any active threads when I went through distutils-sig today... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
Fred Drake wrote: > On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg wrote: >> Where's the benefit of renaming the above three fields ? > > I don't see any benefit here either; if we want to add fields for > Python package or anything else, new (more explicit) field names can > be added, without ever requiring these to be changed. > > As much as having more explicit names would be nice, it's not worth > the disruption caused by deprecation cycles, or the accompanying > confusion. These sorts of changes have very long uptake, while the > clarity benefit is close to non-existent. > >> I'd also remove the "Requires-" from "Requires-Python" and >> simply use "Python" as field name. > > +0 > >> The micro-language should provide a limited number of >> variables to use on the conditions: >> >> python_version = sys.version >> sys_platform = sys.platform > > If we adopt such a micro-language (I'm reserving judgment until I've > had more time to read the relevant PEPs carefully), I'd rather see the > names match what's in the Python runtime more closely, probably only > avoiding the call syntax. We could do that as well, yes. > This would make the examples: > > requires: pywin32; if sys.platform == 'win32' > requires: bar (>1.0); if sys.platform == 'win32' > requires: foo; if platform.machine == 'i386' > requires: bar; if sys.version == '2.4' or sys.version == '2.5' > requires: baz; if 'linux' in sys.platform > >> The same notation could also be used in setup() keyword >> parameters for the meta-data fields, e.g. > > Whatever notation is adopted should be used consistently. Agreed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 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/ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 345
On Tue, Oct 20, 2009 at 5:17 PM, Chris Withers wrote: > Tarek Ziadé wrote: >>> >>> A quick scan of http://www.python.org/dev/peps/pep-0345/ shows no sign of >>> any of the contentious bits of PEP390. What am I missing? >> >> That's the part I have not added yet. Markers are the "sys_platform == >> 'win32" things >> discussed in PEP 390. > > But PEP345 is about the metadata that appears in the installed package, no? > > What use is it having conditionals in there at all? Because we want to add the PEP 390 context dependent markers in there, as explained in PEP 390 (I've updated it yesterday, have a look) It provides the markers to any third party app that wants to read the metadata, and make it avaiable directly at PyPI. >>> (other than that 386 should be accepted and implemented asap...) > > What are the current sticking points? I do remember some discussions > surrounding this but didn't see any active threads when I went through > distutils-sig today... That's from this summer: some folks found the scheme overcomplex and dont want to see it as the standard. I am working in finding back the details. Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake wrote:
> If we adopt such a micro-language (I'm reserving judgment until I've
> had more time to read the relevant PEPs carefully), I'd rather see the
> names match what's in the Python runtime more closely, probably only
> avoiding the call syntax.
> ..
> requires: pywin32; if sys.platform == 'win32'
> ..
I foresee problems with using constants from the python runtime as
they currently stand. Only for the simple reason that the existing
'constants' were good 5 years ago. But won't be good - next year.
For example, 'win32' refers to a specific windows because windows
can now be 64 bit.
Does win32 mean win64? It does now - but it shouldn't.
I propose windows and 32 and 64 as further qualifiers. So for example,
'windows' or 'windows-32' or 'windows-64'. Not to mention 'windows-xp-32'
and 'windows-xp-64' and 'windows-ce'.
Maybe windows-128 is around the corner - who knows..
I respect those sys python constants.. but they are too unspecific
to be used here.
And for linux, what is 'linux2' ? It should just be linux.. to
make it less confusing.
Anyway, I'm coding this all up now into an example.
So far I have in my table..
standard_platform_bits = ('windows','linux','mac',
'xp','vista','7','ce'
'os/x',
'32','64',
'kde','gnome',
'wx','gtk',
'ubuntu','debian','suse','redhat','gentoo',
'centos','symbian'
)
I think we need new constants for package installation. It
will be less confusing. Whichever way we go.
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Alternate static metadata PEP submission...
On Tue, 20 Oct 2009 13:53:31 +0100, Chris Withers wrote: > Be very aware of the problems of proliferating boilerplate code > (buildout has already suffered this): > > - old versions will have to work forever > > - bug fixes are *very* hard to do Well, you're probably right. So I will build an option in to check on the net for an updated version before starting. > > I would like my setup.py to look like: > > from xxx import setup > setup() > > ...and have all the code be in xxx. If xxx is a separately available > package for python<2.7, then fine. > > I would prefer to see "hard logic" in setup.py where there is a good > programming language to support it any everything else in setup.cfg Of course. Code in one place, data in another. > (don't like .info, sorry ;-) ). I'm softening. > My hunch is that for 95% of packages, > setup.py will be nothing more than the above... Hope so David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 390 - new format from setup.cfg
On Tue, 20 Oct 2009 13:28:56 +0100, Chris Withers wrote: > Yes, and yet everytime I ask for the ability specify long description as > a file path relative to the pacakge, I get shouted at ;-) [setup] name = artistflair version = 1.2 description_file = flairdescript.rst A soft voice is calling you from the other (alternate) side... David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, Oct 20, 2009 at 9:33 PM, David Lyon wrote: > On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake wrote: > >> If we adopt such a micro-language (I'm reserving judgment until I've >> had more time to read the relevant PEPs carefully), I'd rather see the >> names match what's in the Python runtime more closely, probably only >> avoiding the call syntax. >> .. >> requires: pywin32; if sys.platform == 'win32' >> .. > > I foresee problems with using constants from the python runtime as > they currently stand. Only for the simple reason that the existing > 'constants' were good 5 years ago. But won't be good - next year. > > For example, 'win32' refers to a specific windows because windows > can now be 64 bit. > > Does win32 mean win64? It does now - but it shouldn't. > > I propose windows and 32 and 64 as further qualifiers. So for example, > 'windows' or 'windows-32' or 'windows-64'. Not to mention 'windows-xp-32' > and 'windows-xp-64' and 'windows-ce'. > > Maybe windows-128 is around the corner - who knows.. > > I respect those sys python constants.. but they are too unspecific > to be used here. No, the architecture is given by platform.machine() so you have it already, by combining a test with sys.platform. > > And for linux, what is 'linux2' ? It should just be linux.. to > make it less confusing. That's how the platform is called, that's not created by Python (it's what uname -s returns) see http://docs.python.org/library/sys.html Tarek. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote: >>> The micro-language should provide a limited number of >>> variables to use on the conditions: >>> >>> python_version = sys.version >>> sys_platform = sys.platform >> >> If we adopt such a micro-language (I'm reserving judgment until I've >> had more time to read the relevant PEPs carefully), I'd rather see the >> names match what's in the Python runtime more closely, probably only >> avoiding the call syntax. > > We could do that as well, yes. +1 on close names + no call syntax but, notice that "python_version" here is: "%s.%s" % sys.version_info[0], sys.version_info[1] thats why we came up with that name, to disinguish it from sys.version (that contains more stuff) Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
On Tue, Oct 20, 2009 at 02:48:58PM +0100, Chris Withers wrote: > Fred Drake wrote: >> On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers >> wrote: >>> As is specifying the setuptools distribution as a requirement when you're >>> already using it... >> >> I don't use setuptools at runtime unless something requires it. >> >> Having it available at install time and run time are two different >> things, and should remain so. > > All I'm saying is that packages shouldn't express a dependency on > setuptools if setuptools is required even before that expression can be > parsed. > > I'm not talking about install or run time... > Are you then talking about build time? -Toshio pgpMGhTB7ndri.pgp Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
Tarek Ziadé wrote:
but, notice that "python_version" here is: "%s.%s" %
sys.version_info[0], sys.version_info[1]
I think you mean:
"{0[0]}.{0[1]}".format(sys.version_info)
or better:
"{0.major}.{0.minor}".format(sys.version_info)
:)
On the odd occasion that .format is less verbose than %, I like pointing
it out!
Eric.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
On Tue, Oct 20, 2009 at 10:20 PM, Eric Smith wrote:
> Tarek Ziadé wrote:
>>
>> but, notice that "python_version" here is: "%s.%s" %
>> sys.version_info[0], sys.version_info[1]
>
> I think you mean:
> "{0[0]}.{0[1]}".format(sys.version_info)
> or better:
> "{0.major}.{0.minor}".format(sys.version_info)
>
> :)
> On the odd occasion that .format is less verbose than %, I like pointing it
> out!
Ah yes, that's nicer :)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] PEP 345 and PEP 386 updates
Tarek Ziadé wrote: > No, the architecture is given by platform.machine() so you have it already, > by combining a test with sys.platform. But platform.machine() returns a 32 bits machine if you run 32 bits python on 64 bits windows. AFAIK, the only reliable way is to use the win32 API: http://blogs.msdn.com/oldnewthing/archive/2005/02/01/364563.aspx In scons (where we limit ourself to pure python code ATM), we tried the registry, but this is not reliable (some braindead softwares install WoW64 registry keys even on 32 bits windows). OTOH, I guess not that many applications need this information: after all, the whole point of WoW64 is to virtualize 32 bits applications so that they believe to run on a conventional 32 bits python. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Alternate static metadata PEP submission...
Hi Chris, Well I put my code up here: https://bitbucket.org/djlyon/original-setup.py-with-metadata/ Plenty on the todo list.. David On Tue, 20 Oct 2009 13:53:31 +0100, Chris Withers wrote: > David Lyon wrote: >> What we actually need, and I am building, is a setup.py script >> that is going to be a 'trimmed' version of distutils that includes >> all neccessary package/application installation code to do the install >> from the setup.info file. > > Be very aware of the problems of proliferating boilerplate code > (buildout has already suffered this): > > - old versions will have to work forever > > - bug fixes are *very* hard to do > > I would like my setup.py to look like: > > from xxx import setup > setup() > > ...and have all the code be in xxx. If xxx is a separately available > package for python<2.7, then fine. > > I would prefer to see "hard logic" in setup.py where there is a good > programming language to support it any everything else in setup.cfg > (don't like .info, sorry ;-) ). My hunch is that for 95% of packages, > setup.py will be nothing more than the above... > > Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
