Distutils-SIG March 2008

distutils-sig@python.org

67 participants
82 discussions

Wow, I think I actually *get* it now!
by Phillip J. Eby 21 Mar '08

21 Mar '08

At 10:08 PM 3/20/2008 +0000, glyph(a)divmod.com wrote (off-list): >No, but in no situation, except one (where I was extremely pressed >for time) was I actually attempting to use setuptools to use any of >its features. My experience of it is: "If a project uses distutils >or apt, installation probably works. If it uses setuptools, it >probably throws a traceback or a wall of text explaining why my >environment is inadequate to perform the installation." Other >people chose to use it and in so doing broke my setup. Manually >copying a few files in these cases was a _lot_ easier than >attempting to diagnose and repair software that I didn't even want to use. > >I am not interesting in packaging or distribution. Far from it: I >run all of my software out of an SVN checkout and I _detest_ being >involved in discussions of deployment or installation. ... >However, the general message of the negative subjective experience I >have had while using setuptools is not FUD. It's an accurate >portrayal of a great deal of frustration. setuptools has, to this >date, not solved a single problem for *me*, personally or >professionally, but it has caused many. distutils, despite its many >flaws, has actually solved quite a few. Actually, this information is VERY helpful. It makes it blindingly obvious to me now that the difference between loving and hating setuptools is whether you're *intentionally* using it, or whether it shows up in your ecosystem uninvited. It also makes the difference in whether you get involved: with no investment in the tool itself, you have minimal motivation to RTFM, ask questions, or fix bugs. And when people in this scenario *do* communicate to me or the distutils-sig, they are much more likely to be impatient and hostile, and more likely to view the system as "fundamentally broken". This makes total sense to me now. I don't have any *solutions* to the problem, mind you, but at least now I understand what before seemed like some sort of bizarre anomaly where literally thousands of people use setuptools and many dozens actually express their happiness with or even love for the system, and then others hate it like they hate Microsoft, or worse. ;-) Meanwhile, from the "outsiders" point of view, setuptools looks like the Matrix or the Borg, happily assimilating the masses, who then start coming to you and say, "But you'll be so much happier once you join us..." ...and off in the distance, you hear a quiet rumbling of zombies chanting "eeeeggs.... eeeeggggs.... mussst havve eggggssss!" :) Hm. So it seems to me that maybe one thing that would help is a "Setuptools Haters' Guide To Setuptools" -- that is, *short* documentation specifically written for people who don't want to use setuptools and want to minimize its impact on their systems. I could probably write something like that fairly easily, now that I have some idea of what to go in it, more than, "the existing documentation sucks". :) Can I count on some non-assimilated persons' help in critiquing such a document and suggesting any topics I miss?

4 3

Request for Input re Packaging
by Jeff Rush 21 Mar '08

21 Mar '08

In researching the state of packaging, I've been reading the archives and all the bug reports filed against distutils. I'd like though to get some examples of particularly troublesome uses of setup.py, to pull together and propose some changes to make their use case a bit easier. So far such cases I've been made aware of are Twisted, numpy and SciPy. If you know of a tough case where the developer had to jump through hoops to make it work, please point me to it. I'd also like to get suggestions of improvements to PyPI, which I've not seen much discussion about. A few I've collected are: - move to https/ssl - improvements re package signing - internal parsing/aggregation of metadata for better queries, and to stop using the filename for version/platform/etc. information. - moving of requirements logic from client into PyPI, where it has db access to the dependency, resolves what packages are needed and delivers a list back to the client for prompting the user for permission, similar to how "yum" interacts today. - a db lint-picking walker that looks for problems on PyPI, such as binary distros w/o a source distro, lack of binaries for those platforms often without compilers, failure to provide a link to a version repo for use with "project==dev". - some auto-generated reports of access statistics and the mix of distutils vs setuptools, those who "registered" w/o "uploading", and perhaps if we get a new classifier assigned, some idea of Python 2.x vs 3.x packages. Last, some of the issues with distutils/setuptools can be solved with zc.buildout. If you have found zc.buildout lacking, please tell me where it fell short so we can see if anything can be done. Thanks for your involvement, -Jeff

5 6

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
by Jeroen Ruigrok van der Werven 21 Mar '08

21 Mar '08

-On [20080320 19:24], Steve Holden (steve(a)holdenweb.com) wrote: >We need to stop protesting that our installation tools are easy enough >and try to get behind the various platforms, be it with Windows >installers, rpms, or other support. We probably aren't doing this >because it's work nobody particularly relishes, and has relatively low >visibility in the developer world. Non-developer Python programmers and >end-users would thank us, though. FreeBSD offers through install of Perl through its ports system a Perl module called 'bsdpan' which registers every module as a package under FreeBSD's package system. Normally ports installs modules as p5-ModuleName, but now it becomes: /var/db/pkg/bsdpan-B-Lint-1.09 And from that point on I can use the pkg* tools. Quite elegant in my opinion. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To regard the fundamental as the essence, to regard things as coarse, to regard accumulation as deficiency, and to dwell quietly alone with the spiritual and the intelligent -- herein lie the techniques of Tao of the ancients.

1 0

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
by Phillip J. Eby 21 Mar '08

21 Mar '08

At 12:33 PM 3/21/2008 +0000, Paul Moore wrote: >On 21/03/2008, Terry Reedy <tjreedy(a)udel.edu> wrote: > > The standard (and to me, preferable) way of dealing with such > things is to > > have an 'installation manager' that can reinstall as well as delete and > > that has a check box for various things to delete. This is what Python > > needs. > >I'd dispute strongly that this is a "standard". It may be preferable, >but I'm not sure where you see evidence of it being a standard. I presume he means that there are a lot of entries in his Add/Remove Programs that work like that, and that it's an emerging standard for Windows. (Certainly I've seen quite a few entries like that in mine, although more often than not they only have one checkbox!) >Could I also point out that *if* such a standard is set up for Python, >bdist_wininst and bdist_msi should be modified to follow it. >Otherwise, it's not a standard, more of competing approach. The best thing to do would be to get a standard (ala PEP 262, but modified by the benefit of experience now) for tracking installed Python package distributions. Then we can standardize on platform tools for managing this data, and include them in the relevant platform distributions. (And that would include making bdist_wininst and bdist_msi follow this installation DB standard.)

1 0

Capsule Summary of Some Packaging/Deployment Technology Concerns
by Jeff Rush 21 Mar '08

21 Mar '08

I was in a Packaging BoF yesterday and, although not very relevant to the packager bootstrap thread, Guido has asked me to post some of the concerns. The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu and such. Everyone had strong expressions of frustration with the status quo and most had tried to resolve their issues but had their patches rejected. I am not taking either side and whether those rejections were justified I cannot say, but the general feeling of their concerns intentionally not being addressed isn't healthy. Several had abandoned setuptools, deeming it a failed solution and others called for a fork. To start, I am not a leader of the group nor do I claim I accurately captured and expressed all their concerns. I apologize to those in the BoF for any misrepresentations. 1. Many felt the existing dependency resolver was not correct. They wanted a full tree traversal resulting in an intersection of all restrictions, instead of a first-acceptable-solution approach taking now, which can result in top-level dependencies not being enforced upon lower levels. The latter is faster however. One solution would be to make the resolver pluggable. 2. People want a solution for the handling of documentation. The distutils module has had commented out sections related to this for several years. 3. A more flexible internal handing of the different types of files is needed. Currently the code, data, lib, etc. files are aggregated at build time and people would like them to be kept separate until install/packaging time. They also want greater flexibility in the kinds of files identified for packaging. There is currently a single plugin entrypoint for file_finding, so people have resorted to abusing the setuptools function find_packages() again and again with different include/exclude args. A solution is to expand the set of entrypoints into finer grained categories. They also want a way to expand the set of categories rather than a fixed set, which can be easily done with entrypoint groups and names. People also want a greater variety of file_finders to be included with setuptools. Instead of just CVS and SVN, they want it to comprehend Mercurial, Bazaar, Git and so forth. 4. They want an uninstall setuptools command. Adding one to remove a specific egg isn't difficult but correctly removing those dependencies that came in with that egg, without breaking later installs can be tricky. This is complicated because there isn't a single global package namespace to manage, when you factor in virtualenv and buildout sandboxes and per-user package areas. This differs from how RPMs and .debs are viewed. 5. There was concern over the .pth mechanism used by setuptools re activation. First, there is a (perceived) performance issue with increasingly adding every ZIP file explicitly onto sys.path. This may or may not be a red herring. The other is the use of a single .pth file to control the list of activated packages. Those who produce distributions would prefer a magic directory into which links to distributions could be dropped, similar to the current best practices for Linux, with /etc/conf.d/, /etc/profile.d/, /etc/xinetd.d/ and so forth. 6. There is a need for more extensibility hooks. People want places to plug in special handling. For example: a) setuptools has a --record option to capture the list of files installed for use by subsequent packaging tools. Some want that list to be available to a setuptools plugin. b) some want hooks for post-build/post-install actions, instead of the current approach of writing a custom build class that handles it all. 7. Many wanted to ability to install files anywhere in the install tree and not just under the Python package. Under distutils this was possible but it was removed in setuptools for security reasons. Custom code can still be written to do this explicitly but this is not popular. Neither setuptools nor distutils has the ability to rename files at install time. A fair question is whether it is the job of setuptools (or any Python packaging solution) to cover all these bases. The risk of not doing the job is that some of those in attendance were rolling their own solutions which do not play well with packages installed using other means, not seeing them. Distutils has intentionally tried to -not- be a general replacement packaging solution, with its support of the "bdist" command for various platform-specific distribution formats. We should continue not trying to replace platform-specific packaging technologies but perhaps improve our control of their creation. As mentioned, some of these concerns can be resolved by adding customization-pressure-release entrypoints to setuptools, and some can be handled with much better documentation of use cases and what to do. And some of it is confusion over packaging libraries versus applications, where setuptools focuses on the former and zc.buildout focuses on the latter. But buildout is very young, maintains isolation from the system Python and was not known to many of the packaging BoF attendees. Some of this may seem down on eggs, but I think they are really cool and would like to see them adopted as the standard for packaging Python software. There are rough spots on setuptools and buildout that would benefit from opening up the process and bringing in more developers, and communicating what they are and more importantly, what they are not. I believe the lack of a coherent packaging and deployment story for Python is hurting its uptake in many sectors and would like to work with others to strengthen this area of Python. -Jeff

8 21

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
by Paul Moore 21 Mar '08

21 Mar '08

On 21/03/2008, Terry Reedy <tjreedy(a)udel.edu> wrote: > However, this Windows user, and I expect most, do NOT expect add-ons > (things under the /Pythonx.y tree) to show up in the add/remove list. That's an interesting counterpoint to my comments. I presume from this that you dislike (and/or never use) bdist_msi and bdist_wininst precisely because they do add such items to the add/remove programs list? My argument is essentially that bdist_wininst set a de facto standard for this. Then, bdist_msi followed it. Now setuptools is trying to change that standard by ignoring it, rather than by discussion of the pros and cons. Personally, I like the current approach, but that's less relevant. > The standard (and to me, preferable) way of dealing with such things is to > have an 'installation manager' that can reinstall as well as delete and > that has a check box for various things to delete. This is what Python > needs. I'd dispute strongly that this is a "standard". It may be preferable, but I'm not sure where you see evidence of it being a standard. Could I also point out that *if* such a standard is set up for Python, bdist_wininst and bdist_msi should be modified to follow it. Otherwise, it's not a standard, more of competing approach. As you can see, my main concern is for consistency :-) Paul.

1 0

Proposal: a 'release' command in distutils
by Tarek Ziadé 21 Mar '08

21 Mar '08

Hello, Working with several PyPI servers is making the command lines quite long and hard to keep up. For instance, If I want to upload an egg on two servers I have to do this: $ python setup.py register sdist bdist_egg upload -r http://my.cool.server/ $ python setup.py register sdist bdist_egg upload -r http://pypi.python.org/pypi Brrrr.... :) The setuptools `alias` command make things easier, but we still need to add in setup.cfg these alias, and have to call several commands to commit just one egg to several places. I would like to propose a new command in distutils to make things easier. This proposal is based on the `.pypirc` syntax of my previous proposal (http://wiki.python.org/moin/EnhancedPyPI) 1. Defining releasing strategies for each repository For each repository, we could add `release` value to tell distutils the sequence to be run when `release` is called:: [distutils] index-servers = pypi my-other-server my-other-server-with-its-own-realm [pypi] repository:http://pypi.python.org/pypi/ username:tarek2 password:secret release:register sdist build_mo bdist_egg upload release-strategy : * [my-other-server] username:tarek2 password:secret repository:http://example.com/repository release:register sdist build_mo bdist_egg upload release-strategy: acme.* specific.package [my-other-server-with-its-own-realm] username:tarek3 password:secret3 repository:http://example2.com/repository realm:acme release:register sdist build_mo bdist_egg upload release-strategy: acme.* acme2.* The `release-strategy` value would be a set of glob-like expressions that will be used to match the package being released, in order to qualify it for the given repository. - when `release` is not provided, the repository is ommited by the release command - when `release` is provided, but not `release-strategy`, the default value for `release-strategy` would be * Of course these are just optional shorcuts 2. Making a release This call: $ cd acme.package $ python setup.py release Would then look in .pypirc where "acme.package" (defined in the package meta-data name) needs to be released, and will do this equivalent sequence: $ python setup.py register sdist build_mo bdist_egg upload -r pypi $ python setup.py register sdist build_mo bdist_egg upload -r my-other-server-with-its-own-realm The interesting thing about glob expressions is that it allows setting a release strategy upon the namespaces. For example, it makes it possible to upload the eggs of a given company to a dedicated server, and defines specific eggs to be released at pypi. Tarek

1 0

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
by Phillip J. Eby 21 Mar '08

21 Mar '08

At 10:48 AM 3/19/2008 -0700, Guido van Rossum wrote: >I don't understand PyPI all that well; it seems poor design that the >browsing via keywords is emphasized but there is no easy way to >*search* for a keyword (the list of all packages is not emphasized >enough on the main page -- it occurs in the side bar but not in the >main text). I assume there's a programmatic API (XML-RPC?) but I >haven't found it yet. http://wiki.python.org/moin/CheeseShopXmlRpc There's also a REST API that setuptools uses: http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api The API was originally designed for screen-scraping an older version of PyPI, but that has been replaced with a "lite" version served from: http://pypi.python.org/simple/ The "lite" version is intended for tools such as easy_install to process, as it consists strictly of links and can be statically cached. Zope Corp., for example, maintains a static mirror of this API, to guard themselves against PyPI outages and slowdowns, since their buildouts can involve huge numbers of eggs, both their own and external dependencies. >I'd love it if you could write or point me to code that takes a >package name and optional version and returns the URL for the source >archive, and the type (in case it can't be guessed from the filename >or the Content-type header). You can probably do that with the XML-RPC API. There's a function to get the versions of a package, given a (case-sensitive) name, and there's a function to get information for uploaded archives, given a name and a version. I originally intended to use it for the PEP 365 approach, but you can get the necessary information in just one static roundtrip using the REST (/simple) HTML API, if you're willing to parse the URLs for version information. (The catch of course being that distutils source distributions don't have unambiguously parseable filenames.) >Hm. Why not just use the existing convention for running setup.py >after unpacking? This works great in my experience, and has the >advantage of having an easy fallback if you end up having to do this >manually for whatever reason. Because I want bootstrap-ees to be able to use the bootstrap mechanism. For example, I expect at some point that setuptools will use other, non-self-contained packages, and other package managers such as zc.buildout et al also want to depend on setuptools without bundling it. > > * calling the bootstrap module 'bootstrap', as in 'python -m > > bootstrap projectname optionalversion'. The module would expose an > > API to allow it to be used programmatically as well as the command > > line, so that bootstrapped packages can use the bootstrap process to > > locate dependencies if they so desire. (Today's package management > > tools, at least, are all based on setuptools, so if it's not present > > they'll need to download that before beginning their own > > bootstrapping process.) > >This sounds like going beyond bootstrapping. My vision is that you use >the bootstrap module (with the command line you suggest above) once to >install setuptools or the alternate package manager of your choice, >and then you can use easy_install (or whatever alternative) to install >the rest. Well, I noticed that the other package managers were writing bootstrap scripts that then download setuptools' bootstrap script and run it as part of *their* bootstrap process... and then I got to thinking that it sure would be nice for setuptools to not have to be a giant monolithic download if I wanted to start using other packages in it... and that it sure would be nice to get rid of all these bootstrap scripts downloading other bootstrap scripts... and then I wrote PEP 365. :) One other thing that PEP 365 does for these use cases that your approach doesn't, is that pkg_resources could detect whether a desired package of a usable version was *already* installed, and skip it if so. So, we've already scaled back the intended use cases quite a bit, as people will have to write their own "is it already there?" and "is it the right version?" checks. > > Without one or the other, the bootstrap tool would have to grow a > > version parsing scheme of some type, and play guessing games with > > file extensions. (Which is one reason I limited PEP 365's scope to > > downloading eggs actually *uploaded* to PyPI, rather than arbitrary > > packages *linked* from PyPI.) > >There are two version parsers in distutils, referenced by PEP 345, the >PyPI 1.2 metadata standard. Yes, and StrictVersion doesn't parse release candidates. And neither LooseVersion nor StrictVersion supports handling multiple pre/post-release tags correctly. (E.g. "1.1a1dev-r2753") > > So, if I had to propose something right now, I would be inclined > to propose: > > > > * using setuptools' version parsing semantics for interpretation of > > alpha/beta/dev/etc. releases > >Can you point me to the code for this? What is its advantage over >distutils.version? It implements version comparison semantics that are closer to programmer expectations. It has also been far more widely used and exposed to more feedback. distutils.version, as far as I know, is really only used by the PEP 345 metadata standard -- which isn't used by *any* automated tools as far as I know, and I'm not sure how many packages bother declaring it. In addition to alpha/beta/candidate/dev versions, it also supports post-release (patchlevel) tags such as svn revision or date-based tags. Here is the code; the docstring is actually longer than the bits that do anything: def parse_version(s): """Convert a version string to a chronologically-sortable key This is a rough cross between distutils' StrictVersion and LooseVersion; if you give it versions that would work with StrictVersion, then it behaves the same; otherwise it acts like a slightly-smarter LooseVersion. It is *possible* to create pathological version coding schemes that will fool this parser, but they should be very rare in practice. The returned value will be a tuple of strings. Numeric portions of the version are padded to 8 digits so they will compare numerically, but without relying on how numbers compare relative to strings. Dots are dropped, but dashes are retained. Trailing zeros between alpha segments or dashes are suppressed, so that e.g. "2.4.0" is considered the same as "2.4". Alphanumeric parts are lower-cased. The algorithm assumes that strings like "-" and any alpha string that alphabetically follows "final" represents a "patch level". So, "2.4-1" is assumed to be a branch or patch of "2.4", and therefore "2.4.1" is considered newer than "2.4-1", which in turn is newer than "2.4". Strings like "a", "b", "c", "alpha", "beta", "candidate" and so on (that come before "final" alphabetically) are assumed to be pre-release versions, so that the version "2.4" is considered newer than "2.4a1". Finally, to handle miscellaneous cases, the strings "pre", "preview", and "rc" are treated as if they were "c", i.e. as though they were release candidates, and therefore are not as new as a version string that does not contain them, and "dev" is replaced with an '@' so that it sorts lower than than any other pre-release tag. """ parts = [] for part in _parse_version_parts(s.lower()): if part.startswith('*'): if part<'*final': # remove '-' before a prerelease tag while parts and parts[-1]=='*final-': parts.pop() # remove trailing zeros from each series of numeric parts while parts and parts[-1]=='00000000': parts.pop() parts.append(part) return tuple(parts) component_re = re.compile(r'(\d+ | [a-z]+ | \.| -)', re.VERBOSE) replace = {'pre':'c', 'preview':'c','-':'final-','rc':'c','dev':'@'}.get def _parse_version_parts(s): for part in component_re.split(s): part = replace(part,part) if not part or part=='.': continue if part[:1] in '0123456789': yield part.zfill(8) # pad for numeric comparison else: yield '*'+part yield '*final' # ensure that alpha/beta/candidate are before final To check a parse_version() value for stability, you can just loop over it looking for any part <"*foo" where "foo" is the desired minimum stability. That is, if you find a '*a' and you don't want alphas, then this version's no good. This lets you also distinguish between a beta that you might accept, from an in-development snapshot of a beta, that you wouldn't. >What's wrong with just running "setup.py install"? I'd rather continue >existing standards / conventions. Of course, it won't work when >setup.py requires setuptools; Actually, it will, if the setup script uses the current ez_setup bootstrapping method for setuptools. However, I'd like to get *rid* of that bootstrapping method, and replace it with this one. That's why I'd prefer that the bootstrap approach use a different entry point for launching, and why I want the module to expose an API, and why I don't really want the bootstrapper to actually "install" anything. For one thing, it means dealing with installation *options*. Your prototype doesn't pass through any command-line options to the script, so people would have to use a ~/.pydistutils.cfg file in order to control the installation options, for example. (Which then can break if the packager included a setup.cfg that was supposed to be overridden on the command line...) Probably this seems a lot more messy to me, because I've had my face directly planted in the mess for a number of years now, and I know that, for example, people bitched and moaned excessively about not being able to use --prefix with easy_install, the way they could with 'setup.py install'. And maybe my experiences aren't all relevant here; I'm just not very good at turning them off. My skepticism for the setup.py-based approach is at close to "new scheme for removing the GIL" level, because I've gone through a lot of pain to get easy_install from the stage where it looked a lot like your bootstrap prototype, to something that actually works, most of the time, for arbitrary distutils packages. :) And unfortunately, some of the hurdles will require a few release cycles to show up. And hey, if you're okay with that, cool. I just think that as soon as it gets out in the field, people will use it far outside anything we expect it to be used for, and if there's not a bright line for the *packager* to cross, I think we'll have people unhappy with the tool. If you have to do a special step to make something bootstrappable, then when the tool doesn't work, the user will ask the packager to take the special step. However, if the tool allows the user to *point* it at any package, and it randomly (from the user's POV) fails, then the tool (and Python) will be blamed for the failure. Because even though the bootstrap tool is "not a package manager", if it's close enough to look like "a simpler easy_install", people will try to use it as one, and blog about how bootstrap is broken and should support installation options, etc. (I suppose at this point easy_install is something of a counter-example to this worry; people can and do now give packagers patches to make their setup scripts more compatible with easy_install, in cases where the package does extensive distutils modification. OTOH, easy_install is a de facto standard, where bootstrap will be de jure. What does that mean in practice? Heck if I know. :) I guess people will hate on you instead of me, then, so maybe I should view that as an improvement. :) (It also makes it easier to understand your reluctance to be in any way associated with eggs, but there's a big difference between eggs and easy_install, and IMO your approach leans more towards the relative vices of easy_install than the relative virtues of eggs. But oh well.))

16 22

The Breaking of distutils and PyPI for Python 3000?
by Jeff Rush 20 Mar '08

20 Mar '08

As I'm digging into packaging issues here at PyCon, a couple of Python 3000 related matters occur to me. As I'm new to the Python 3000 development, if these have already been addressed in prior discussions, I apologize for your time. 1. What is the plan for PyPI when Python 3.0 comes out and dependencies start getting satisfied from distribution across the great divide, e.g. a 3.0-specific package pulls from PyPI a 2.x-specific package to meet some need? Are there plans to fork PyPI, apply special tags to uploads or what? While binary distributions are tagged with the Python version, source distributions are not. And of course a dependency expression as it stands today for "SomePackage > 2.4" may pull 3.0 to satisfy it. 2. There have been attempts over the years to fix distutils, with the last one being in 2006 by Anthony Baxter. He stated that a major hurdle was the strong demand to respect backward compatibility and he finally gave up. One of the purposes of Python 3.0 was the freedom to break backward compatibility for the sake of "doing the right thing". So is it now permissible to give distutils a good reworking and stop letting compatibility issues hold us back? -Jeff

7 11

Re: [Distutils] [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
by M.-A. Lemburg 20 Mar '08

20 Mar '08

On 2008-03-20 13:42, Thomas Heller wrote: > M.-A. Lemburg schrieb: >> About the platform.py changes: if someone could provide the return >> values of sys.getwindowsversion() for 64bit versions of Windows >> XP and Vista, I could add support for it (don't have a 64bit version >> of Windows available to check myself). > > This is the output of a 32-bit Python running on "Windows XP Professional > x64 Edition, Version 2003, Service Pack 2": > > C:\Python24>ver > > Microsoft Windows [Version 5.2.3790] > > C:\Python24>python > Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> sys.getwindowsversion() > (5, 2, 3790, 2, 'Service Pack 2') Thank you ! Anyone with a 64bit Vista ? Or even better: a page documenting what to expect from the system call behind the sys.getwindowsversion() API ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2008) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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

1 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG March 2008