Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 28-nov-2006, at 22:05, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) +1. We've been running into this problem on the Mac since Apple started shipping Python. There's another standard place that is searched on MacOS: a per-user package directory ~/Library/Python/2.5/site-packages (the name site- packages is a misnomer, really). Standardising something here is less important than for vendor-packages (as the effect can easily be gotten by adding things to PYTHONPATH) but it has one advantage: distutils and such could be taught about it and provide an option to install either systemwide or for the current user only. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 09:34 am, [EMAIL PROTECTED] wrote: There's another standard place that is searched on MacOS: a per-user package directory ~/Library/Python/2.5/site-packages (the name site- packages is a misnomer, really). Standardising something here is less important than for vendor-packages (as the effect can easily be gotten by adding things to PYTHONPATH) but it has one advantage: distutils and such could be taught about it and provide an option to install either systemwide or for the current user only. Yes, let's do that, please. I've long been annoyed that site.py sets up a local user installation directory, a very useful feature, but _only_ on OS X. I've long since promoted my personal hack to add a local user installation directory into a public project -- divmod's Combinator -- but it would definitely be preferable for Python to do something sane by default (and have setuptools et. al. support it). I'd suggest using ~/.local/lib/pythonX.X/site-packages for the official UNIX installation location, since it's what we're already using, and ~/.local seems like a convention being slowly adopted by GNOME and the like. I don't know the cultural equivalent in Windows - %USERPROFILE%\Application Data\PythonXX maybe? It would be nice if site.py would do this in the same place as it sets up the darwin-specific path, and to set that path as a module global, so packaging tools could use site.userinstdir or something. Right now, if it's present, it's just some random entry on sys.path. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Hi Anthony, On Wed, Nov 29, 2006 at 12:53:14AM +1100, Anthony Baxter wrote: python2.4 distutils is excluded by default. I still have no idea why this was one - I was also one of the people who jumped up and down asking Debian/Ubuntu to fix this idiotic decision. I could not agree more. Nowadays, whenever I get an account on a new Linux machine, the first thing I have to do is reinstall Python correctly in my home dir because the system Python lacks distutils. Wasteful. (There are some applications and libraries that use distutils at run-time to compile things, and I'm using such applications and libraries on a daily basis.) Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Objecttype of 'locals' argument in PyEval_EvalCode
This seems a bug. In revision 36714 by Raymond Hettinger, the
restriction that locals be a dict was relaxed to allow any mapping.
On 11/29/06, Daniel Trstenjak [EMAIL PROTECTED] wrote:
Hi all,
I would like to know the definition of the 'locals' object given to
PyEval_EvalCode. Has 'locals' to be a python dictionary or a subtype
of a python dictionary, or is it enough if the object implements the
necessary protocols?
The python implementation behaves different for the two following code
lines:
from modul import symbol
from modul import *
In the case of the first one, it's enough if the object 'locals' implements
the necessary protocols. The second one only works if the object 'locals'
is a type or subtype of dictionary.
The problem lies in Python-2.5/Python/ceval.c:
static int
import_all_from(PyObject *locals, PyObject *v)
{
...
4046 value = PyObject_GetAttr(v, name);
4047 if (value == NULL)
4048err = -1;
4049 else
4050err = PyDict_SetItem(locals, name, value);
4051 Py_DECREF(name);
...
}
Changing PyDict_SetItem in line 4050 with PyObject_SetAttr could fix it.
Best Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Guido van Rossum schrieb: I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) Patch #1298835 implements such a vendor-packages directory. I have reopened the patch to reconsider it. I take your message as a +1 for that feature. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Objecttype of 'locals' argument in PyEval_EvalCode
Hi, On Wed, Nov 29, 2006 at 07:39:25AM -0800, Guido van Rossum wrote: This seems a bug. In revision 36714 by Raymond Hettinger, the restriction that locals be a dict was relaxed to allow any mapping. Mea culpa, I thought I reviewed this patch at the time. Fixed in r52862-52863. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote: Yes, let's do that, please. I've long been annoyed that site.py sets up a local user installation directory, a very useful feature, but _only_ on OS X. I've long since promoted my personal hack to add a local user installation directory into a public project -- divmod's Combinator -- but it would definitely be preferable for Python to do something sane by default (and have setuptools et. al. support it). I'd suggest using ~/.local/lib/pythonX.X/site-packages for the official UNIX installation location, since it's what we're already using, and ~/.local seems like a convention being slowly adopted by GNOME and the like. I don't know the cultural equivalent in Windows - %USERPROFILE%\Application Data\PythonXX maybe? It would be nice if site.py would do this in the same place as it sets up the darwin-specific path, and to set that path as a module global, so packaging tools could use site.userinstdir or something. Right now, if it's present, it's just some random entry on sys.path. +1 from me also for the concept. I'm not sure I like ~/.local though - -- it seems counter to the app-specific dot-file approach old schoolers like me are used to. OTOH, if that's a convention being promoted by GNOME and other frameworks, then I don't have too much objection. I also think that setuptools has the potential to be a big improvement here because it's much easier to install and use egg files than it is to get distutils to DTRT with setup.py. (I still detest the command name 'easy_install' but hey that's still fixable right? :). What might be nice would be to build a little more infrastructure into Python to support eggs, by say adding a default PEP 302 style importer that knows how to search for eggs in 'nests' (a directory containing a bunch of eggs). What if then that importer were general enough, or had a subclass that implemented a policy for applications where prefix/lib/ pythonX.X/app-packages/application became a nest directory. All my app would have to do would be to drop an instance of one of those in the right place on sys.path and Python would pick up all the eggs in my app-package directory. Further, easy_install could then grow an -- install-app switch or somesuch that would install the egg in the app- package directory. I haven't really thought this through so maybe it's a stupid idea, but ISTM that would make management, installation, and use in an application about as simple as possible. (Oh yeah, add an -- uninstall switch too :). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRW4cpnEjvBPtnXfVAQK/7wP/fS/MnVm6Msq6kB3qJce5BOK4NFo0ewGG uephuUfux+AWKMhl6KIIe7xeT6yO4yS/U/DF0sZ35JoOK8ebyH0JO/pup+lCfA3r ODQL45s+G1yycZDjUh3/a9+RakdhpfBRvjU3V/IFH7ayiM9PIHxKjTIzjXo3m1Pq 1hxb5BHS/8I= =kPE7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Barry Warsaw wrote: I'm not sure I like ~/.local though - -- it seems counter to the app-specific dot-file approach old schoolers like me are used to. Problems with that are starting to show, though. There's a particular Unix account that I've had for quite a number of years, accumulating much stuff. Nowadays when I do ls -a ~, I get a directory listing several screens long... The whole concept of hidden files seems ill- considered to me, anyway. It's too easy to forget that they're there. Putting infrequently-referenced stuff in a non-hidden location such as ~/local seems just as good and less magical to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Objecttype of 'locals' argument in PyEval_EvalCode
[Guido van Rossum] This seems a bug. In revision 36714 by Raymond Hettinger, the restriction that locals be a dict was relaxed to allow any mapping. [Armin Rigo] Mea culpa, I thought I reviewed this patch at the time. Fixed in r52862-52863. Armin, thanks for the check-ins. Daniel, thanks for finding one of the cases I missed. Will load a unittest for this one when I get a chance. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 28/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote: I personally agree that Linux standards should specify a standard layout for a Python installation, and that it should be the one that make install generates (perhaps after make install is adjusted). Whether or not it is the *LSB* that needs to specify that, I don't know, because the LSB does not specify a file system layout. Instead, it incorporates the FHS - which might be the right place to define the layout of a Python installation. For the LSB, it's more import that import httplib gives you something working, no matter where httplib.py comes from (or whether it comes from httplib.py at all). Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this contract in spirit is broken by vendor repackaging they should: * Call the binaries something else because it is NOT python any more. * Setup the installation layout so that it does NOT conflict or overlap with the standard layout. * Call the whole package something else. But I can't see that happening. Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ? I would strongly prefer _not_ write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate This is not a standard python runtime to the python run time, early failure (in the application) with informative error messages becomes much more viable. Eg sys.vendor_variant would be orthogonal to sys.version and sys.version_info Given: python -c import sys; print sys.version GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) A regex on sys.version does not seem like a good way to get positive confirmation I'm using the Canonical variant (pun intended) python -c from distutils.util import get_platform; print get_platform() Tells me nothing about the vendor of my linux distribution. Except, ironically, when it says ImportError Cheers, Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 29 Nov, 11:49 pm, [EMAIL PROTECTED] wrote: On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote: I'd suggest using ~/.local/lib/pythonX.X/site-packages for the official UNIX installation location, ... +1 from me also for the concept. I'm not sure I like ~/.local though - -- it seems counter to the app-specific dot-file approach old schoolers like me are used to. OTOH, if that's a convention being promoted by GNOME and other frameworks, then I don't have too much objection. Thanks. I just had a look at the code in Combinator which sets this up and it turns out it's horribly inconsistent and buggy. It doesn't really work on any platform other than Linux. I'll try to clean it up in the next few days so it can serve as an example. GNOME et. al. aren't promoting the concept too hard. It's just the first convention I came across. (Pardon the lack of references here, but it's very hard to google for ~/.local - I just know that I was looking for a convention when I wrote combinator, and this is the one I found.) The major advantage ~/.local has for *nix systems is the ability to have a parallel *bin* directory, which provides the user one location to set their $PATH to, so that installed scripts work as expected, rather than having to edit a bunch of .foorc files to add to your environment with each additional package. After all, what's the point of a per-user install if the software isn't actually installed in any meaningful way, and you have to manually edit your shell startup scripts, log out and log in again anyway? Another nice feature there is that it uses a pre-existing layout convention (bin lib share etc ...) rather than attempting to build a new one, so the only thing that has to change about the package installation is the root. Finally, I know there are quite a few Python developers out there already using Combinator, so at least there it's an established convention :). I also think that setuptools has the potential to be a big improvement here because it's much easier to install and use egg files than it is to get distutils to DTRT with setup.py. (I still detest the command name 'easy_install' but hey that's still fixable right? :). What might be nice would be to build a little more infrastructure into Python to support eggs, by say adding a default PEP 302 style importer that knows how to search for eggs in 'nests' (a directory containing a bunch of eggs). One of the things that combinator hacks is where distutils thinks it should install to - when *I* type python setup.py install nothing tries to insert itself into system directories (those are for Ubuntu, not me) - ~/.local is the *default* install location. I haven't managed to make this feature work with eggs yet, but I haven't done a lot of work with setuptools. On the easy_install naming front, how about layegg? What if then that importer were general enough (...) These all sound like interesting ideas, but they're starting to get pretty far afield - I wish I had more time to share ideas about packaging, but I know too well that I'm not going to be able to back them up with any implementation effort. I'd really like Python to use the ~/.local/bin / ~/.local/lib convention for installing packages, though.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 12:34 am, [EMAIL PROTECTED] wrote: The whole concept of hidden files seems ill- considered to me, anyway. It's too easy to forget that they're there. Putting infrequently-referenced stuff in a non-hidden location such as ~/local seems just as good and less magical to me. Something like ~/.local is an implementation detail, not something that should be exposed to non-savvy users. It's easy enough for an expert to show it if they want to - ln -s .local local - but impossible for someone more naive to hide if they don't understand what it is or what it's for. (And if they try, by clicking a checkbox in Nautilus or somesuch, *all* their installed software breaks.) This approach doesn't really work unless you have good support from the OS, so it can warn you you're about to do something crazy. UI designers tend to get adamant about this sort of thing, but I'll admit they go both ways, some saying that everything should be exposed to the user, some saying that all details should be hidden by default. Still, in the more recent UNIX desktops, the let's hide the things that the user shouldn't see and just work really hard to make them work right all the time camp seems to be winning. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote: GNOME et. al. aren't promoting the concept too hard. It's just the first convention I came across. (Pardon the lack of references here, but it's very hard to google for ~/.local - I just know that I was looking for a convention when I wrote combinator, and this is the one I found.) ~/.local/ is described in the XDG Base Directory Specification: http://standards.freedesktop.org/basedir-spec/latest/ On the easy_install naming front, how about layegg? Actually, why not just egg? That's parallel to rpm at least, and there isn't such a command installed on my Ubuntu box already. (Using synaptic to search for egg resulted in little that actually had egg in the name or short description; there was wnn7egg (a Wnn7 input method), but that's really it.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
At 03:20 AM 11/30/2006 +, [EMAIL PROTECTED] wrote: One of the things that combinator hacks is where distutils thinks it should install to - when *I* type python setup.py install nothing tries to insert itself into system directories (those are for Ubuntu, not me) - ~/.local is the *default* install location. I haven't managed to make this feature work with eggs yet, but I haven't done a lot of work with setuptools. easy_install uses the standard distutils configuration system, which means that you can do e.g. [install] prefix = ~/.local in ./setup.cfg, ~/.pydistutils.cfg, or /usr/lib/python2.x/distutils/distutils.cfg to set the default installation prefix. Setuptools (and distutils!) will then install libraries to ~/.local/lib/python2.x/site-packages and scripts to ~/.local/bin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
At 06:49 PM 11/29/2006 -0500, Barry Warsaw wrote: What might be nice would be to build a little more infrastructure into Python to support eggs, by say adding a default PEP 302 style importer that knows how to search for eggs in 'nests' (a directory containing a bunch of eggs). If you have setuptools generate your scripts, the eggs are searched for and added to sys.path automatically, with no need for a separate importer. If you write standalone scripts (not using setup.py develop or setup.py install), you can use pkg_resources.require() to find eggs and add them to sys.path manually. If you want eggs available when you start Python, easy_install puts them on sys.path using .pth files by default. So, I'm not clear on what use case you have in mind for this importer, or how you think it would work. (Any .egg file in a sys.path directory is already automatically discoverable by the means described above.) What if then that importer were general enough, or had a subclass that implemented a policy for applications where prefix/lib/ pythonX.X/app-packages/application became a nest directory. Simply installing your scripts to the same directory as the eggs they require, is sufficient to ensure this. Also, since eggs are versioned, nothing stops you from having one giant systemwide egg directory. Setuptools-generated scripts automatically adjust their sys.path to include the specific eggs they need - and need can be specified to an exact version if desired (e.g. for system admin tools). I haven't really thought this through so maybe it's a stupid idea, but ISTM that would make management, installation, and use in an application about as simple as possible. (Oh yeah, add an -- uninstall switch too :). Yeah, that's targeted for the nest package management tool, which I may have some time to work on someday, in my copious free time. :) In the meantime, 'easy_install -Nm eggname; rm -rf /path/to/the.egg' takes care of everything but the scripts. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 04:11 am, [EMAIL PROTECTED] wrote: On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote: GNOME et. al. aren't promoting the concept too hard. It's just the first convention I came across. (Pardon the lack of references here, but it's very hard to google for ~/.local - I just know that I was looking for a convention when I wrote combinator, and this is the one I found.) ~/.local/ is described in the XDG Base Directory Specification: http://standards.freedesktop.org/basedir-spec/latest/ Thanks for digging that up! Not a whole lot of meat there, but at least it gives me some env vars to set / check... On the easy_install naming front, how about layegg? Actually, why not just egg? That works for me. I assumed there was some other reason the obvious answer hadn't been chosen :).___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 29, 2006, at 10:20 PM, [EMAIL PROTECTED] wrote: Another nice feature there is that it uses a pre-existing layout convention (bin lib share etc ...) rather than attempting to build a new one, so the only thing that has to change about the package installation is the root. That's an excellent point, because in configure-speak I guess you could just use --prefix=home/.local and everything would lay out correctly. (I guess that's the whole point, eh? :) One of the things that combinator hacks is where distutils thinks it should install to - when *I* type python setup.py install nothing tries to insert itself into system directories (those are for Ubuntu, not me) - ~/.local is the *default* install location. I haven't managed to make this feature work with eggs yet, but I haven't done a lot of work with setuptools. That's really nice. So if I sudo python setup.py install it'll see uid 0 and install in the system location? On the easy_install naming front, how about layegg? I think I once proposed hatch but that may not be quite the right word (where's Ken M when you need him? :). What if then that importer were general enough (...) These all sound like interesting ideas, but they're starting to get pretty far afield - I wish I had more time to share ideas about packaging, but I know too well that I'm not going to be able to back them up with any implementation effort. Yeah, same here, so I'll shut up now. I'd really like Python to use the ~/.local/bin / ~/.local/lib convention for installing packages, though. I'm sold. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRW5ninEjvBPtnXfVAQKZBgP+MC1p3ipJbJn8ayhYyO73hdeWHpeHWd82 F4pFwkAuiXMWZ9/le1XW61+ODfSSti0RbBEiJeuul5dHP7+DlhXHyXrCf6Zzab4e PTerySTgc8AtI8L2VZzAaVU9PlzmKw0dp4s2pigNbGb3FRbH/m/ZwhSSYfeQTA3U gdA5YQq7CD0= =CJ9T -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 04:36 am, [EMAIL PROTECTED] wrote: easy_install uses the standard distutils configuration system, which means that you can do e.g. Hmm. I thought I knew quite a lot about distutils, but this particular nugget had evaded me. Thanks! I see that it's mentioned in the documentation, but I never thought to look in that section. I have an aversion to .ini files; I tend to assume there's always an equivalent Python expression, and it's better. Is there an equivalent Python API in this case? I don't know if this is a personal quirk of mine, or a reinforcement of Talin's point about the audience for documentation documentation. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 29, 2006, at 11:45 PM, Phillip J. Eby wrote: [Phillip describes a bunch of things I didn't know about setuptools] As is often the case, maybe everything I want is already there and I've just been looking in the wrong places. :) Thanks! I'll read up on that stuff. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRW5phnEjvBPtnXfVAQKwLgP/doK7aF5zGknK4JCv+rjO4xXKWRwjB0Vk B08Ee2HlSTcqSe8YIqMOSCRa8LcW86hEFipJmIi8vzcPv0Tr6y+i6yMTq0zhYeyh lvc7E7wdMY+U78/+ffeDLBNESXkZRzaiv0aH4ZkBf3xOebj58vCNBHlmzfT0WeFj EMnJut6jOnM= =mlIW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
At 05:10 AM 11/30/2006 +, [EMAIL PROTECTED] wrote: On 04:36 am, [EMAIL PROTECTED] wrote: easy_install uses the standard distutils configuration system, which means that you can do e.g. Hmm. I thought I knew quite a lot about distutils, but this particular nugget had evaded me. Thanks! I see that it's mentioned in the documentation, but I never thought to look in that section. I have an aversion to .ini files; I tend to assume there's always an equivalent Python expression, and it's better. Is there an equivalent Python API in this case? Well, in a setup.py there's an options or some such that can be used to provide effective command-line option overrides in-line, but that doesn't help for systemwide default configurations, like the files I mentioned. It's effectively only a substitute for setup.cfg. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Robin Bryce schrieb: Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this contract in spirit is broken by vendor repackaging they should: * Call the binaries something else because it is NOT python any more. * Setup the installation layout so that it does NOT conflict or overlap with the standard layout. * Call the whole package something else. I think that would be counter-productive. If applied in a strict sense, you couldn't call it Python anymore if it isn't in /usr/local. I see no point to that. It shouldn't be called Python anymore if it doesn't implement the Python language specification. No vendor is modifying it in such a way that print Hello stops working. Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ? I'm not sure in what applications that would be useful. I would strongly prefer _not_ write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate This is not a standard python runtime to the python run time, early failure (in the application) with informative error messages becomes much more viable. Again: none of the vendors modifies Python in a way that what you get is not a standard Python runtime. They *all* are standard Python runtimes. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
