Mailman 3 June 2004 - Distutils-SIG

Re: [Distutils] Installing large applications
by Bob Ippolito 16 Jun '04

16 Jun '04

On Jun 15, 2004, at 2:36 PM, Tim Peters wrote: > [Fred L. Drake, Jr.] > ... >> Distutils should not allow the installaion 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, > > 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? > >> 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. > The only ways to do that on Windows are to install such components > under the > Python installation's Lib/site-packages/, or to add registry keys. > Neither > way allows two distinct versions of ZODB to be used with a single > Python > installation. > > I think you were intending to address this, because of the earlier: > >> One interesting aspect for such applications is that it is often >> desirable to install multiple versions of the application on a single >> system. > > There's only one Lib/site-packages/ per Python installation on > Windows, and > it's inside the Python tree (*all* of Python is in "the Python tree" on > Windows -- binaries, libraries, docs, test suite, tools, everything). What about pth files? I use them all the time for adding additional site directories. Try making a pth file with something like this in it and dropping it into the system site-packages: import site, os; site.addsitedir(os.path.expanduser(os.path.join("~", "YourApplication", "site-packages"))) -bob

3 5

imagine if you had a diploma
by Brigitte Rutledge 15 Jun '04

15 Jun '04

1 0

Atencion!
by Cancun 15 Jun '04

15 Jun '04

1 0

build_py support from setuptools
by Fred L. Drake, Jr. 15 Jun '04

15 Jun '04

I'd like to merge the build_py improvements from setuptools into the distutils build_py command. This would add: - an easy way to install additional data files into a package - the ability to provide both individual modules and packages at the same time This would affect Python 2.3.5 and 2.4. I'll modify setuptools to only "take over" the build_py command if it needs to. Any objections? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

4 8

gfj333@aol.com
by GFJ333＠aol.com 15 Jun '04

15 Jun '04

please remove from mailing list thank-you

1 0

Re: [Distutils] Installing scripts
by Stefan Seefeld 15 Jun '04

15 Jun '04

Tim Peters wrote: > [Fred L. Drake, Jr.] >>I *think* we agreed that stripping a .py extension for scripts on Unix is >>acceptable, but it's not clear that any Unix-oriented users other than >>myself were involved in the discussion. > > > There were two others. One was a True Believer in extensionless scripts on > Unix, the other liked extensions on Unix scripts (but seemingly not so > intently as the former hated them). ok, here is a third: I believe it's an unfortunate fact that extensions are interpreted as metainfo and on some systems not considered part of the name. Whenever possible I'd vote to preserve the full filename intact, as that is a form of the principle of least surprize. If the user wants some platform-specific manipulation of script filenames at install time, he should indicate that to distutils with some special option. >>I don't think we can simply rip off .py extensions on Unix, since that >>changes the set of installed names for packages that support older >>versions of Python/distutils; > > > Have to agree that visible changes are visible. > > >>there probably needs to be some explicit gesture that this is desired in >>the call to distutils.core.setup() (or maybe just in setup.cfg). >> >>I asked about silently not installing .pyw scripts on Unix, but I've not >>seen any responses on that issue. > > > I responded: -1. You can't guess whether a .pyw script will work on Unix > from its extension alone. right. The very concept of an extension doesn't make much sense under unix. I don't even know whether the 'file' utility uses that for some types, probably not. In any case, there isn't any semantics associated with extensions, so users are free to name their scripts however they want without the system interpreting anything differently. That shouldn't change. > I don't think anyone so far would object to an explicitly-triggered scheme > to strip script extensions on Unix, although some people may be unhappy with > distributions that choose to use it. I think it should strip all script > extensions (.py, .pyw, .pl, .sh, .tcl -- all extensions period). yes, as long as it is explicit (read: user-controllable) everything is fine. A document on 'portable packaging with distutils' will certainly help. Regards, Stefan

1 0

access information
by mose＠castor.ucc.ie 14 Jun '04

14 Jun '04

Dear Distutils-sig Great s,e,x ! Awesome videos! Enchanting stories! On the best adu1t site Love For Lust Special offer: Buy V1a,gra and get Free Access http://www.loveforlust.biz/?m=distutils-sig@python.org nggzoror nggt wylfh dzo xnoqew qxxdi kj okztarwg y pcxdteg ttdw tvaflycp tnbx zbgzt cgq ttnwpr czlgv vb wbnuefcr h aqtgqci xtdg tzxbcwmi rijn jzinf kgl lyvrpx cnqfu zf rbhonqhx c vhbewhp cucb ovqmyfed aeit fqtut orj kalpwt hymja df rqdywhya p rghaapp rabt

1 0

Re: [Distutils] Installing scripts
by Mark W. Alexander 14 Jun '04

14 Jun '04

On Mon, Jun 14, 2004 at 05:55:46PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr.] > > Did we reach any conclusions regarding script installation? I think > > there are still some issues. > > Really <wink>? > > > I *think* we agreed that stripping a .py extension for scripts on Unix is > > acceptable, but it's not clear that any Unix-oriented users other than > > myself were involved in the discussion. > > There were two others. One was a True Believer in extensionless scripts on > Unix, the other liked extensions on Unix scripts (but seemingly not so > intently as the former hated them). I agreed on removing the extenstions on installed scripts. I believe the other person weighed in that he prefered having the extensions with the qualification "in a development environment". > > I don't think we can simply rip off .py extensions on Unix, since that > > changes the set of installed names for packages that support older > > versions of Python/distutils; > > Have to agree that visible changes are visible. So packages that are installed with "python setup.py install" won't necessarily install over the former .py scripts. Serves 'em right for not using bdist_* and the native package manager (insert evil laughter here). > > there probably needs to be some explicit gesture that this is desired in > > the call to distutils.core.setup() (or maybe just in setup.cfg). > > > > I asked about silently not installing .pyw scripts on Unix, but I've not > > seen any responses on that issue. > > I responded: -1. You can't guess whether a .pyw script will work on Unix > from its extension alone. If, e.g., it's a script that brings up a Tk UI, > then it should work fine on Unix, but giving it a .pyw extension is the only > way to prevent it from opening a useless new DOS box too on Windows. Unix > still doesn't need the extension, while Windows still does. > > Should, e.g., a .sh script be installed on Windows? It can't work, but it > may still be good "documentation" for multilingual developers. Should a > .bat script be installed on Unix? .pl? There's no end to this. I think a qualified "yes, for now" followed up with smarter bdist_* commands that support platform specific metadata tuning in setup.cfg later. > > I'd like to have a better idea of how much agreement there might be > > before starting to work on a patch. > > There's near-unanimous agreement that scripts should have appropriate > extensions on Windows. I noted that I'd be -1 on a scheme that attempted to > do so by having distutils guess at appropriate extensions (so strip > extensions that are already there, or specify appropriate extensions > explicitly). > > I don't think anyone so far would object to an explicitly-triggered scheme > to strip script extensions on Unix, although some people may be unhappy with > distributions that choose to use it. I think it should strip all script > extensions (.py, .pyw, .pl, .sh, .tcl -- all extensions period). As long as the shebang magic was properly managed, I agree. mwa -- Mark W. Alexander slash(a)dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/

1 0

Re: our offer
by Rickey Corbett 14 Jun '04

14 Jun '04

1 0

building multi-platform
by Stefan Seefeld 14 Jun '04

14 Jun '04

hi there, I'm trying to use distutils to build on windows native as well as cygwin, and I just had to notice that the content of sysconfig.get_config_vars() differs wildly between the two. Why is that ? Isn't distutils' scope also to unify the build process for different platforms ? Unfortunately the 'build_ext' command that ships with distutils isn't flexible enough for me, so I'm rolling my own. But to do that with minimal efford I intended to use all the configuration data I could get out of distutils.sysconfig... Thanks, Stefan

1 0