Mailman 3 March 2004 - Distutils-SIG

Re: ***SPAM?*** Re: Hello
by tommie＠iae.nl 21 Mar '04

21 Mar '04

This account will cease to exist on: Dit account wordt opgeheven op: 1 sep 2003 Thomas.

1 0

Distutils BOF at PyCon 2004
by Fred L. Drake, Jr. 19 Mar '04

19 Mar '04

I've added a proposed list of topics for a Distutils BOF for PyCon: http://www.python.org/cgi-bin/moinmoin/DistutilsBof If anyone would like to add to the list or expand on it, or add their name to it as planning to attend, that would be great. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

2 1

Distutils at the PyCon 2004 sprints
by Fred L. Drake, Jr. 18 Mar '04

18 Mar '04

I've not heard anything about either of the proposed Distutils sprints for next week. Just as a reminder, these are: - general distutils improvements and wart smashing (http://www.python.org/cgi-bin/moinmoin/DistUtils20) This is generally about avoiding some of the current warts rather than dealing with major new functionality, with the exception of the PEP 262 (http://www.python.org/peps/pep-0262.html) installation database. It's hard to get a good sense of what people's priorities are from the wiki page, but it would certainly be good to knock out some of the more long-standing warts. - dependency support (http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies) This is Phillip Eby's proposal for adding dependency support to distutils, including automatic download and installation of required packages. I don't know what other people's reaction is to his proposal; aspects of it are certainly interesting and mesh well with the PEP 262 installation database. I'd really like to see some improvements happening in either of these areas. I don't know what it takes to get these sprints to go from proposed to concrete, or if we can just take space by squatting (unlikely to be well received ;). Who else will be at the sprints and willing to spend a day or two on distutils? In case there aren't enough outstanding distutils tasks, I'll be glad to propose a few more that I'm going to need to deal with anyway. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

6 15

Distutils BOF at PyCon 2004
by Fred L. Drake, Jr. 17 Mar '04

17 Mar '04

I've added a distutils birds-of-a-feather sesion to the BoF schedule at: http://www.python.org/cgi-bin/moinmoin/PyConBofs I'll try to get a set of proposed topics written up this evening. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

Your message to xslt awaits moderator approval
by xslt-admin＠gnome.org 16 Mar '04

16 Mar '04

Your mail to 'xslt' with the subject Re: Re: Re: Your document Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

::::::::!!!!!! ABSOLUTELY NEW !!!!!!:::::::: laurie
by Support commonality 15 Mar '04

15 Mar '04

::::::::!!!!!! ABSOLUTELY NEW !!!!!!:::::::: ::::::::::: FRESH T.E.E.N.S. MODELS ::::::::::: NeVeR s_h_o_t before, NeVeR f_u_c_k_e_d so w.i.l.d.l.y before, NeVeR C.uM-SMeAReD ---SO--- HEAvi1Y BEeFoRE. TH.E.SE baBES ! ! ! are s.-i.-m.-.p.-l.-y WAY too k_i_n_k_y AND REALLY have a. s.t.unning ***S*E*X*UAL*** ima.g-ination. >From s.o.l.o P=O=S=I=N=G and d*i*l*d*o GA_M_ES to a.we.so.me !!! MULTI *_0_R_G_1_E_S_* and G=A=N=G=B=A=N=G=S. http://mmm-sex.biz/90mt/?OIb5l !!! A.N.A.L., O.R.A.L. , DOUBLE AND TRIPLE V_A_G_I_N_A F_U_C_K - EvErYThInG that ___youve___ b.ee.n L00KING FOR IS HERE !!!!!! TH.E.SE h0t --T-E-E-N-I-E-S-- are R.EA.DY. F0R EvErYThInG JUST T0 ___pLeAsE___ YOU !!!!!! FRESH T.E.E.N B*0*D*Y IS ALL YOU N_E_E_D T0 J.E.r.K =OFF= M O S T @@ p.l.e.a.s.a.n.t.l.y @@ !!! LES-BI-AN S_H_O_W_S, L.IVE. ==S=T=R=I=P== S_H_O_W_S AND MO--RE !!!! S.-I.-G.-N U.-P.- !!!! http://mmm-sex.biz/90mt/?0xaw6 moses auntie gerry collaborate ciceronian aspect platitude clamorous senor polysaccharide bauxite atkins olive property canaveral astonish aperiodic somebody revelation dauphin newtonian weal delia christenson acquiescent eater mayfair carcass chartroom . colloquy awoke melville despite coralberry passivate except greenbelt adjourn ppm lombardy tapir relieve diocesan dandelion urinary astrophysical ammunition breakdown . chuckle drexel quartile quackery incarcerate durward giacomo deceitful conklin doff spicy gaunt allele antiphonal bile augite bleary buckskin charybdis destructor oscillatory arachnid encyclopedic kava blurry populous handymen acrylate paramount . sightseer awry israel sentient ordain projector toolkit inception hurt acclamation commendation flop laurie genii pregnant indent these catenate sexy ash stout concessionaire camp guesswork can't cardiovascular earsplitting bloodstream quaff indicter necropsy dawson .

1 0

Developer Information from Seekford Solutions, Inc.
by Seekford Solutions, Inc. 15 Mar '04

15 Mar '04

Greeting from Seekford Solutions, Inc., I am sure you have to get your software development projects done on time and under budget. Don't we all? If you don’t use third-party components, it can be next to impossible. No one wants to reinvent the wheel, especially at a significantly higher cost and sacrificing your precious time. I personally like to spend time with my family and friends; developers need to have lives too. Seekford Solutions, Inc. is a third party component developer that allows you easily integrate Internet communication functionality into your new and existing applications. With very few lines of code you can send and receive emails, upload and download files via HTTP and FTP, synchronize with atomic clocks for highly accurate time stamping and clock setting, communicate with news group servers, and even secure data with highly complex (easy to use though) algorithms for data hashing. Lets not take up too much more of your time. Please check out our selection of .NET and ActiveX technologies at our website: http://www.SeekfordSolutions.com Clients around the world using a large variety of programming languages currently use our controls, many Fortune 500 companies included. Our components are available from a number of major distributors and all products come with free e-mail technical support. Thank you, Customer relations Seekford Solutions, Inc. http://www.SeekfordSolutions.com Tampa, FL If you do not want to receive communications from us, please just reply with REMOVE in the subject.

1 0

SWIG support (or lack thereof)
by Lars Immisch 13 Mar '04

13 Mar '04

Dear all, I have a few SWIG generated python modules, and I like distutils. distutils only sort-of supports swig. It passes very limited arguments to swig. Most importantly missing for me were macro definitions and include paths. I have attached a minimally intrusive patch that: - reuses include_dirs, define_macros and undef_macros from the C target - adds 'extra_swig_args' (which I need for at least -shadow) The patch was generated from the Python 2.3.2 and should be applied in the distutils directory. The patch solves my immediate problem, but it might be even better to add 'swig_include_dirs', 'swig_define_macros' and 'swig_undef_macros' to the Extension arguments. I volunteer for another patch if there are chances it will be accepted. - Lars --- core.orig Fri Mar 12 23:55:27 2004 +++ core.py Fri Mar 12 23:56:21 2004 @@ -54,7 +54,8 @@ 'define_macros', 'undef_macros', 'library_dirs', 'libraries', 'runtime_library_dirs', 'extra_objects', 'extra_compile_args', 'extra_link_args', - 'export_symbols', 'depends', 'language') + 'extra_swig_args', 'export_symbols', 'depends', + 'language') def setup (**attrs): """The gateway to the Distutils: do everything your setup script needs --- extension.orig Fri Mar 12 23:55:18 2004 +++ extension.py Fri Mar 12 23:57:41 2004 @@ -94,6 +94,7 @@ extra_objects=None, extra_compile_args=None, extra_link_args=None, + extra_swig_args=None, export_symbols=None, depends=None, language=None, @@ -115,6 +116,7 @@ self.extra_objects = extra_objects or [] self.extra_compile_args = extra_compile_args or [] self.extra_link_args = extra_link_args or [] + self.extra_swig_args = extra_swig_args or [] self.export_symbols = export_symbols or [] self.depends = depends or [] self.language = language --- command/build_ext.orig Fri Mar 12 20:16:24 2004 +++ command/build_ext.py Sat Mar 13 23:52:22 2004 @@ -16,6 +16,7 @@ from distutils.dep_util import newer_group from distutils.extension import Extension from distutils import log +from distutils.ccompiler import gen_preprocess_options # An extension name is just a dot-separated list of Python NAMEs (ie. # the same as a fully-qualified module name). @@ -81,6 +82,8 @@ "specify the compiler type"), ('swig-cpp', None, "make SWIG create C++ files (default is C)"), + ('extra-swig-args', None, + "extra swig options (for example -shadow)"), ] boolean_options = ['inplace', 'debug', 'force', 'swig-cpp'] @@ -108,6 +111,7 @@ self.force = None self.compiler = None self.swig_cpp = None + self.extra_swig_args = None def finalize_options (self): @@ -322,7 +326,8 @@ 'libraries', 'extra_objects', 'extra_compile_args', - 'extra_link_args'): + 'extra_link_args', + 'extra_swig_args'): val = build_info.get(key) if val is not None: setattr(ext, key, val) @@ -429,7 +434,7 @@ # First, scan the sources for SWIG definition files (.i), run # SWIG on 'em to create .c files, and modify the sources list # accordingly. - sources = self.swig_sources(sources) + sources = self.swig_sources(sources, ext) # Next, compile the source code to object files. @@ -492,7 +497,7 @@ target_lang=language) - def swig_sources (self, sources): + def swig_sources (self, sources, extension): """Walk the list of source files in 'sources', looking for SWIG interface (.i) files. Run SWIG on all that are found, and @@ -530,6 +535,16 @@ swig_cmd = [swig, "-python"] if self.swig_cpp: swig_cmd.append("-c++") + + for esa in extension.extra_swig_args: + swig_cmd.append(esa) + + opt = gen_preprocess_options(extension.define_macros + + extension.undef_macros, + extension.include_dirs) + + for o in opt: + swig_cmd.append(o) for source in swig_sources: target = swig_targets[source]

1 0

getting value from setup.cfg
by V.Selvam 11 Mar '04

11 Mar '04

Hi all, Im writting a python module distribution for a small applicatoin. I want to take some value( eg., prefix) from the setup.cfg file and use it in my distribution script. How can i get this from python script ?? Can any one help me in this ?? Thanks in advance Rgds V.Selvam

1 0

Unravelling installation schemes
by Phillip J. Eby 10 Mar '04

10 Mar '04

I'm working on implementing distutils dependencies, as described at: http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies and I've run into a bit of a hitch. In order to run dependencies' setup scripts, I need to be able to pass along command line options from the parent setup script. But, it's not quite that simple. The distutils framework allows people to specify quite a few options at multiple levels. For example, you can specify a different C compiler to the build_lib and build_ext commands, and a third one to the build command itself! Next, there's path munging and alternate installation schemes, along with the 'extra_path' support, install-lib overriding purelib and platlib, the distribution name embedded in the install-headers path, and so on. My brain is approaching critical mass for explosion. :) Now, add to this some additional requirements that are specific to dependency management. I need to know where stuff is being installed, so that when I check for the existence of a dependency, I'm not fooled by it not being on sys.path currently. And, what if a dependency exists on extra_path? [sob, sniff] I guess I'm beginning to see why nobody else has tackled this up to now. :) Of course, for maybe half the installs it would suffice to just run 'setup.py install' on the dependencies. For about half of the remaining situations, it would probably suffice to just pass along whatever options were specified on the parent setup script's command line, verbatim. It's the remaining scenarios that are tough: * Some joker uses a relative path on the command line (could fix, if we know which arguments are directories) * Non-build/non-install commands (could maybe fix by only copying options for build, install, and subcommands thereof) * Somebody uses an explicit --install-lib or install_lib --install-dir (fixable, but it could screw things up if they really should've been specifying platlib or purelib or one of the higher-level options) * Somebody uses an explicit install --install-headers or install_headers --install-dir (aaagh!) So far, I'm thinking that about the only thing to do is: 1. Go through all the command-line options for install, build, and their subcommands 2. If *any* '--install-X' option exists apart from 'install-base' or 'install-platbase', raise holy heck and stop the gravy train when trying to install dependencies. Ask the user to either change their options, or to manually run the child setup with appropriate options, specifying where it is and what to do. 3. Only pass recognized-to-be safe options from build and its subcommands. (Which is probably going to equate to just the compiler option, include-) Fix up directory options from the install command to be absolute. Barf if an inplace build_ext was specified. 4. Don't use any options that came from config files. If it was a global config, it'll apply to the child setup automatically. If it came from the local setup.cfg, it *shouldn't* apply to the child. Whew. So here's the thing... am I making this too hard? Is there a better way to deal with options to child setups? I look at all the zillions of options to the individual commands, and I think about when and why I might specify those options, I think I mostly *wouldn't* want them passing through to the child setups. Maybe the simplest thing to do would be to make a list of "safe" command-line options that will be passed to children, and issue warnings for the rest? Or maybe stop the build if any options would be ignored, unless a "go ahead anyway" option is given? What do y'all think? I guess I'm now leaning towards that last option... simply dump out on-screen all the command-line arguments that aren't safe, and show what *would* be passed to the child setup, and show what arguments would be needed to provide a command line that will force the build to proceed anyway, and also how to run the child setup manually (since the target will have already been downloaded and extracted to the temporary directory). This won't address complex installation options, but then, if somebody has complex installation options, they can probably deal with a little complexity for installing the dependencies, I guess. There are a few other issues floating about, mostly to do with sys.path, .pth files, and installation to locations other than site-packages. But I think I'll leave those thoughts to another post. :)

2 3