Mailman 3 June 2004 - Distutils-SIG

Network Associates Webshield - e-mail Content Alert
by administrator＠lucasfilm.com 21 Jun '04

21 Jun '04

Our policy prohibits ZIP file enclosures. Your message was NOT sent to the intended recipient.

1 0

DoYouNeed EverydaySoftware? more...
by Dziuba＠bobillot-2-81-57-228-188.fbx.proxad.net 20 Jun '04

20 Jun '04

http://RxJr.CAJGBBDH.biz/?l4nWnCR_qVsK7RlFKkn http://gncr.ECNFHHFA.info/?UDWtq9U2tY_haUUEzxu bye-bye

1 0

You`ve got 1 VoiceMessage!
by Utente 19 Jun '04

19 Jun '04

Dear Customer! You`ve got 1 VoiceMessage from voicemessage.com website! Sender: Utente You can listen your Virtual VoiceMessage at the following link: http://virt.voicemessage.com/index.listen.php25affv or by clicking the attached link. Send VoiceMessage! Try our new virtual VoiceMessage Empire! Best regards: SNAF.Team (R).

1 0

software
by menefy＠ele.tue.nl 18 Jun '04

18 Jun '04

Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://pvitgevz.cgnacmg.info/?MviRixgPpkT9yggkaqhm Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://abhrv.ifbccch.info/?eZMPgveNniR7wKeempdzptb ngpxvhtf baiwz vxqdjre rjawx pzxghyv norj xloylz ulvq dycvcug dqdtp aayzvmon xlam jmlfztx dgzziuf lli gcjg bicnypk kqzwf k bfuyt

1 0

Re: [Distutils] Installing large applications
by Jim Fulton 17 Jun '04

17 Jun '04

Tim Peters wrote: > [Fred L. Drake, Jr.] > ... ... >>A new command-line option will be added to allow the location to be >>changed. "install --application <name>" will cause the installation to >>occur in /opt/<name>/ (or some Windows equivalent) > > > There seems to be an assumption that <name> includes a version number. Then > plain \<name> or <drive>:\<name> may be suitable on Windows. I don't understand this. How does the presence or absense of a version number affect wither you use a root directory or a drive letter? ... > The plural "directories" confuses this for me. It reads as if a single run > of "install.py --application" may actually specify multiple installation > directories. Or is it that the Windows installer will be modified to allow > *an* (singular) alternate installation directory? The point is that the windows installer for an application should allow the user to select a directory to install into. (IMO, the default, for an application, should be in "Program Files".) > >>and provide the same behavior for applications by default. > > > I'm not sure how much this proposal is intended to address. An application > like Zope expects some of its components (like ZODB) to show up on sys.path, > without any runtime code of its own fiddling sys.path to make that happen. No. Generally an applucatin will have it's own library area(s), which will be added to sys.path on startup. So, the version of ZODB that comes with an application would typically be installed in the application's library area and would override any version installed in the standard library or site packages. In addition, users will often want to install custom versions of libraries for an application. Zope actually takes this a step further by having "instance" installations. To set up a zope installation, you first install the software (hopefulling using a distutils-based installer) and then use an installed program to create one or more Zope "instances". Each instance runs a Zope application server and has instance-specific configuation, data, *and* library areas. Someone could install custom versions of software into an instance area, overriding other versions in the Zope or Python library areas. So, in summary, an application might add multiple librariy areas. The application *is* responsible for adding these to sys,path on startup. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

4 5

Installing large applications
by Fred L. Drake, Jr. 17 Jun '04

17 Jun '04

Distutils has a moderately good reputation for being easy to use for packaging and installing Python libraries (modules and packages). For everything else, it's pretty clearly a work-in-progress. For large applications, distutils has much of the needed support, but needs a bit of polishing to make it easier to work with. I'll characterize a "large application" as having a large body of Python modules and packages, one or more programs that provide the user interface (either command line or GUI, or both), and possibly data and configuration. The Python libraries which form part of an application may or may not be usable outside the application, but are often not intended for general use. Zope is an example of a large application; there are several others. One interesting aspect for such applications is that it is often desirable to install multiple versions of the application on a single system. This is often needed when evaluating new versions to determine whether an upgrade may be performed safely, or whether new features are sufficiently valuable to incur the cost and risk of data migration. On Unix, the "install --home <someplace>" command and option can be used to create an appropriate installation, but that is not supported on Windows. It would be desirable to be able to indicate in the call to distutils.core.setup() that a distribution is an application that wants this kind of installation. The value for the indicator could be a name that's used to compute the platform-dependent default location. For example, if the indicator were "ZopeX3-3.0.0", the default location on Unix might be "/opt/ZopeX3-3.0.0/". The default layout of files within an application may match that of the --home installation scheme, or may not, but should be the same across platforms. Proposal -------- A new keyword, "application", will be supported by distutils.core.setup(). The value will be the name of the application and should be used to compute the default installation location. The installation scheme will match that used by --home on Unix, and support for an equivalent scheme will be added on Windows. A new command-line option will be added to allow the location to be changed. "install --application <name>" will cause the installation to occur in /opt/<name>/ (or some Windows equivalent) instead of the default. "install --application /some/path" will cause the installation to occur in /some/path/. Distutils should not allow the installation to use an existing directory without an explicit override from the user (--force?). The Windows installer will be modified to allow alternate installation directories to be supported, and provide the same behavior for applications by default. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

4 6

T0p Quality S0ftware at the L0west Possible Priice from Harding's S0ftSh0p
by Brent Allred 17 Jun '04

17 Jun '04

I sometimes give myself admirable advice, but I am incapable of taking it. Why so large a cost, having so short a lease, does thou upon your fading mansion spend? He enjoys much who is thankful for little. I shoot the Hippopotamus with bullets made of platinum, because if I use the leaden one his hide is sure to flatten em. Our grand business is not to see what lies dimly at a distance, but to do what lies clearly at hand. Once the state has been founded, there can no longer be any heroes. They come on the scene only in uncivilized conditions. Absurdity. A statement or belief manifestly inconsistent with one's own opinion. A fair request should be followed by the deed in silence. If you keep thinking about what you want to do or what you hope will happen, you don't do it, and it won't happen. The wise man does at once what the fool does finally. I have never let my schooling interfere with my education. I sometimes give myself admirable advice, but I am incapable of taking it. Every great achievement is the victory of a flaming heart. No great intellectual thing was ever done by great effort.

1 0

FREE RX Prescriptions - Valium-Prozac-Xanax-Soma ...
by Savannah Benoit 16 Jun '04

16 Jun '04

1 0

Package/Module/Recipe Versioning, Aggregation and Distrobution
by distutils-sig＠claytonbrown.net 16 Jun '04

16 Jun '04

I have been developing a bootstrap loader to enable module/package & python interpretor versioning/specification at time of import within a script. This is primarily to encourage code re-use/portablility (satisfying dependancies on multiple machines & platforms), and allow revision control and coexistence of packages, a particular weak point of python in my experience (I could be just doing things wrong). I am interested now in how such versioned packages could be agregated and made avaliable through a centralised service such as PyPi/CPAN, and as to wether such functionality described below will be a spanner in the works for distrobution techniques. ---------my actual question ------------------ To people familiar with distrobuting python projects, and associated tools, eg (py2exe, disutils, PyPi, freeze, etc) Which is not my string point in python, is this going to cause headaches with the way the afore mentioned tools work. Can this below mentioned versioning/package retrieval/recipe retrieval be easily integrated with a CPAN like service such as PyPi & http://python.org/peps/pep-0273.html in a logical manner, allowing platform specific, versioned packages to be agregated and made available automagically at time of import, or through some form of dependancy checker. ------------------------------------ -----functionality------------ This is similar to a technique seen in PythonMegaWidgets and a discussion I found of David Aschers on versioning. I have made my intial version of this avaliable on aspn. This is comprised of two parts, versioner.py & version_loader.py (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/285215), versioner walks a site-packages tree identifying folder structures where versioned packages occur, and distrobutes version_loader.py as __init__.py in the parent folder of this versioned packages, it also creates empty placeholder __init__.py's & autoloaders (from foldername import * - where script name = folder name and no __init__.py exists ) so that you can automagically have "from package.folder.folder.script import method, etc ,etc" Admittedly Mark Hammonds win32, win32com, etc, didn't work at first inspection but I am happy for such packages to remain locally with site-packages as these are not cross platform packages anyhow, however all other packages I have migrated to my versioned site packages directory have played nicely in tests made. (for example: bsddb3, ClientCookie, DCOracle2, Ft, id3, log4py, logging, mx, OpenSSL, PIL, psyco, psyco2, PythonMagick, soaplib, wxPython, xmlplus ) With the manual hack of dragging any built binaries (.so, .dll, .pyd, etc) for said package from DLLS,etc into versioned package folder (OK when this is dpendant on system services eg MySqld, BerkleyDB, etc this could get difficult). The impact on python syntax for this is minimal with local variables such as: _foo_version_ = '1.2.3.4' #where point depth is level of compatibility required import foo Optionally. _python_version_ = '2.2.2' #again point depth is variable I further intend to remove all of the pollution this make of local namespace once the import has been performed. And have not gone through extensive testing nor bug fixes as yet, but all seems to work quite nicely. Ultimately I would love an extension to the python core syntax along the lines of: import foo version 2.3.4.5 (with inate platform inspection suffixing on package name)#to give the behaviour I have implements I thought I had seen a PEP on this though cant seem to find this. ------------------------------------ ------------extension to this------------ Ultimately I would like to achieve a CPAN like web retrieval of versioned packages/scripts which are referenced yet not available, though doing this at time of import perhaps if local variable is declared: e.g. _PyPi_download_ = 1, where if a version is specified it will retrieve that version else defaulting to latest. I would like to extend this with recipes as well, Eg. import recipe.aspn_python.stringutil.md5hash as md5hash import recipe.parnassus.stringutil.utf8escape as ut8esc import recipe.claysstuff.stringutil.utf8unescape as ut8unesc Where one could register a base foldername, and their lookup service with a central weblookup services which fires a search for a packge/module/scriptname which returns standardised xml results, to allow retrieval of the said package, storing it in the path you have nominated for versioned-packages/recipes (perhaps in site.py), perhaps even allowing syntax to import all packages from source/category/subcategory/etc eg aspn_python.category.* Having PyPi agregate packages (perhaps with unit tests also) and mirror seems logical, bundling all immediate depandancies within a single archive also seems logical. Having packages also nominate dependancies could be a huge benifit: Eg. requires['package'] = '1.2.3' Or standard dependancies.xml in base folder of package, ok this may be simplistic, modelling dependancies is a whole separate issue but for example <depandancies> <python version='2.2.2'/> <built-against>libpthread.so.0</depend> #using ldd </python> <platform os='linux' distro='shrike'> <service name='gcc' version='3.22'/> #using locate(if present) | binaryName -v [perhaps this is a little flimsy] <service name='php' version='4.2'/> </platform> <packages> <name='proprietarycode.foo' version='1.2.4' service='http://foo.com/lookup.cgi|php|etc' user='root' pass='secret'/> #for private packages <name='aspn.util.bar' version='1.2.4'/> #uses Pypi to get search service to locate/download package <packages> </depandancies> ------------------------------------ I thought I may as well put out some of the concerns I came across with versioned package managment, and some of the enhancements I could see being of benifit for discussion. My apologies if I have missed such discussions in these groups I have only recently joined these groups. Apologies if any of these seems unclear

1 0

Service Offered
by Cora Shultz 16 Jun '04

16 Jun '04

<html> <head> <meta http-equiv="Content-Language" content="en-us"> <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Are You Losing Sales Due To Your Alexa Rankings</title> </head> <body> <a href="http://www.alexapowerranker.com/index.html"> <img border="0" src="../images/Alexa%20Power%20Ranker%20copy.jpg" width="499" height="106"></a> Are You Losing Sales Due To Your Alexa Rankings? <a href="http://www.alexapowerranker.com/index.html"> <img src="../images/moneymkr.jpg" border="0" width="187" height="135"></a> Alexa.com will determine how successful your website is in the eyes of 99% of all internet marketers.  Start Lowering Your Alexa Ranking's, Visit Our Site To Learn How! <a href="www.AlexaPowerRanker.comwww.AlexaPowerRanker.comhttp://www.AlexaPowerRanker…">www.AlexaPowerRanker.com</a>         </body> </html>

1 0