Mailman 3 May 2004 - Distutils-SIG

Receive big discounts on MS Win 2000, XP, Office, Adobe, Corel products from Todd's Stuff Store
by Sonya Pina 17 May '04

17 May '04

1 0

Have a nice day! //the righteousness of Jesus Christ, therefore man is justified
by Cheerios P. Epitomizing 17 May '04

17 May '04

Get easy money! http://members.lycos.co.uk/lancer131/1/ --- when the temptation comes again with power, he is carried

1 0

RE: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2
by Moore, Paul 17 May '04

17 May '04

From: Ronald Oussoren > On 15-mei-04, at 0:23, Lars Immisch wrote: >> From Bob: >> >>> Not all operating systems have a usable package management system >>> (Win32, Mac OS X, probably others). >> >> What's wrong with Installer.app and/or PackageMaker? > Both are installers, not package management systems. There is no public > interface for listing which packages are installed and uninstalling > packages, let alone dependency management. Hmm. I'm not sure I see what you're saying here. If you're saying that a "usable package management system" needs to support a "public interface" for listing which packages are installed, uninstalling packages, and dependency management (which you'd need to define more clearly) then Windows certainly does have one (albeit a bit primitive). Applications which wish to participate in the standard "Add/Remove Programs" interface have to register certain registry keys, so to some extent that would count as a "public interface". Listing & uninstall only, there's no dependency management, but it's a start. And it's what the current bdist_wininst uses, so it's supported by distutils right now. What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do... Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

3 2

thoughts on distutils 1 & 2
by has 17 May '04

17 May '04

Hello List, Very quiet here, so thought I would toss in some notes I've been making regarding Python's module system, the current DistUtils 1.x and some of the proposals I've seen for Distutils 2. These notes are very rough so I dunno how much sense they'll make to anyone else in their current state, but I figure it's better to pitch them in to find out if there's any interest in discussing them further than spend time polishing them if there isn't. Let us know what you think, and we can take it from there if folk are interested. Regards, has ------- Issues: http://www.python.org/cgi-bin/moinmoin/DistUtils20 states: "The ultimate goal: Must be backwards-compatible with existing setup.py scripts." This is both a red herring and likely recipe for DU2 becoming a big ball of mud before it's even out the door... - Compatibility for existing setup.py scripts can easily be ensured by retaining DU1. DU1 should be declared at end of its development life. DU1 API may eventually be re-implemented on top of DU2, allowing DU1 core to be ditched to reduce maintenance cost. Deprecate DU1 API. - DU1 doesn't scale down as well as it could/should. Doesn't scale up as well as it could/should. Current DU2 proposals don't seem to address these points, seeking only to add new material on top rather than reexamine/reevaluate existing architecture. Some current DU2 proposals smack of rampant architecture astronomy, lacking sufficient evaluation of their potential cost or whether the same goals could be achieved through other, simpler means. - DU2 provides an opportunity to review everything learnt over course of DU1 development and do it better. DU1 development has stagnated under its own weight. DU1 architecture is a rat's nest. Not a good base to build DU2 on. Better to design afresh: assemble list representative range of use cases and their relative frequencies in real-world use, determine "ideal" solution, determine "practical" solution. "Practical" solution = "ideal" solution minus anything that would prove too disruptive to Python, or too expensive for the benefits it'd provide, or where existing material from DU1 could be leveraged in at less cost than reimplementing from scratch. ------- Recommend: - Before adding new features/complexity, refactor current _design_ to simplify it as much as possible. Philosophy here is much more hands-off than DU1; less is more; power and flexibility through simplicity: make others (filesystem, generic tools, etc.) do as much of the work as possible; don't create dependencies. -- e.g. c.f. Typical OS X application installation procedure (mount disk image and copy single application package to Applications folder; no special tools/actions required) versus typical Windows installation procedure (run InstallShield to put lots of bits into various locations, update Registry, etc.) or typical Unix installation procedure (build everything from source, then move into location). Avoiding overreliance on rigid semi-complex procedures will allow DU2 to scale down very well and provide more flexibility in how it scales up. - Eliminate DU1's "Swiss Army" tendencies. Separate the build, install and register procedures for higher cohesion and lower coupling. This will make it much easier to refactor design of each in turn. - Every Python module should be distributed, managed and used as a single folder containing ALL resources relating to that module: sub-modules, extensions, documentation (bundled, generated, etc.), tests, examples, etc. (Note: this can be done without affecting backwards-compatibility, which is important.) Similar idea to OS X's package scheme, where all resources for [e.g.] an application are bundled in a single folder, but less formal (no need to hide package contents from user). - Question: is there any reason why modules should not be installable via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the package IS the module" (see above) would allow a good chunk of both existing and proposed DU "features" to be gotten rid of completely without any loss of "functionality", greatly simplifying both build and install procedures. --Replace current system where user must explicitly state what they want included with one where user need only state what they want excluded. Simpler and less error-prone; fits better with user expectations (meeting the most common requirement should require least amount of work, ideally none). Manifest system would no longer be needed (good riddance). Most distributions could be created simply by zipping/tar.gzipping the module folder and all its contents, minus any .pyc and [for source-only extension distributions] .so files. -- In particular, removing most DU involvment from build procedures would allow developers to use their own development/build systems much more easily. - Installation and compilation should be separate procedures. Python already compiles .py files to .pyc on demand; is there any reason why .c/.so files couldn't be treated the same? Have a standard 'src' folder containing source files, and have Python's module mechanism look in/for that as part of its search operation when looking for a missing module; c.f. Python's automatic rebuilding of .pyc files from .py files when former isn't found. (Q. How would this folder's contents need to be represented to Python?) - What else may setup.py scripts do apart from install modules (2) and build extensions (3)? -- Most packages should not require a setup.py script to install. Users can, of course, employ their own generic shell script/executable to [e.g.] unzip downloaded packages and mv them to their site-packages folder. -- Extensions distributed as source will presumably require some kind of setup script in 'src' folder. Would this need to be a dedicated Python script or would something like a standard makefile be sufficient? -- Build operations should be handled by separate dedicated scripts when necessary. Most packages should only require a generic shell script/executable to zip up package folder and its entire contents (minus .pyc and, optionally, .so files). - Remove metadata from setup.py and modules. All metadata should appear in a single location: meta.txt file included in every package folder. Use a single metadata scheme in simple structured nested machine-readable plaintext format (modified Trove); example: ------------------------------------------------------------------ Name roundup Version 0.1.0 Intended Audience End Users/Desktop Developers System Administrators License OSI Approved Python Software Foundation License Topic Communications Email Office/Business Software Development Bug Tracking Dependencies etc... ------------------------------------------------------------------ - Improve version control. Junk current "operators" scheme (=, <, >, >=, <=) as both unnecessarily complex and inadequate (i.e. stating module X requires module Y (>= 1.0) is useless in practice as it's impossible to predict _future_ compatibility). Metadata should support 'Backwards Compatibility' (optional) value indicating earliest version of the module that current version is backwards-compatible with. Dependencies list should declare name and version of each required package (specifically, the version used as package was developed and released). Version control system can then use both values to determine compatibility. Example: if module X is at v1.0 and is backwards-compatible to v0.5, then if module Y lists module X v0.8 as a dependency then X 1.0 will be deemed acceptable, whereas if module Z lists X 0.4.5 as a dependency then X 1.0 will be deemed unacceptable and system should start looking for an older version of X. - Make it easier to have multiple installed versions of a module. Ideally this would require including both name and version in each module name so that multiple modules may coexist in same site-packages folder. Note that this naming scheme would require alterations to Python's module import mechanism and would not be directly compatible with older Python versions (users could still use modules with older Pythons, but would need to strip version from module name when installing). - Reject PEP 262 (installed packages database). Complex, fragile, duplication of information, single point of failure reminiscent of Windows Registry. Exploit the filesystem instead - any info a separate db system would provide should already be available from each module's metadata. -- http://freespace.virgin.net/hamish.sanderson/

7 10

didn't go to college - that's ok we'll give you a diploma
by Williams Yoder 16 May '04

16 May '04

1 0

no need to lie on your application, we can sell you a verifiable university degree
by Rolland Steele 15 May '04

15 May '04

1 0

Re: did I send this to you?
by Jose Travis 14 May '04

14 May '04

1 0

Detected as SPAM: TEST
by Dominique Unruh SpamDetector 12 May '04

12 May '04

Your message has accidentially been classified as SPAM. It therefore has been deleted. To bypass the SPAM filter, please send a new message containing the string DNIQ_THIS_IS_NO_SPAM in body or subject. Yours, Dominique Unruh.

1 0

Your message to Trasno awaits moderator approval
by trasno-bounces＠ceu.fi.udc.es 08 May '04

08 May '04

Your mail to 'Trasno' with the subject Mail Delivery (failure trasno(a)ceu.fi.udc.es) Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/trasno/858040b84d3e14912b92802…

1 0

7- your opinion is valuable
by Nelson Hayes 06 May '04

06 May '04

1 0