Re: [Python-Dev] eggs now mandatory for pypi?
David Lyon wrote: > On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" wrote: >>> One could say that much of the setuptools cloud came about because of >>> the lack of the queryable download url. Setuptools does a lot of work >>> here to 'work-around' the ommission on pypi of a package download url. >> >> I think you two have missed my email to PJE. >> >> In summary: >> >> PyPI already does have mechanism for querying download URLs. >> >> http://wiki.python.org/moin/PyPiXmlRpc >> >> It only lacks some more meta-data that would be required to >> match up the user's configuration with the one used in the >> uploaded URLs. >> >> And it would be handy to have a mechanism to just upload the >> URL data rather than the whole package. Looking at distutils' >> upload command, PyPI currently appears to only support uploads >> of the package file itself. >> >> Basically, most of the mechnisms are already there, they just need >> some extra care. > > Maybe you're right. I'll look into it. > >> BTW: Who would I need to contact for the PyPI side to work out >> an upload_url distutils command ? > > pypi is on sourceforge... ask to become a developer I guess.. I know that the issue tracker for PyPI is (still) on SF, but development appear to happen elsewhere and I can't find any contact information on the PyPI web pages. Is Richard Jones still working on it ? They I could contact him directly to hash this out. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Ian Bicking a écrit : > I'm coming in late and breaking threading, but wanted to reply to > Tarek's original email: > > This is verifiable, stable, and to varying degrees concrete > (virtualenv being more concrete than buildout, which tends more > towards the declarative). Is that a friday troll ? declarative over control ? > > What virtualenv does could certainly be in the Python interpreter (and > much more compact as a result, I am sure). PYTHONHOME does it to a > degree, though binding a script to a environment through the > interpreter listed in #! is more stable than the implicit environment > of PYTHONHOME. workingenv used an environmental variable (PYTHONPATH, > before PYTHONHOME existed) and it caused problems. Also virtualenv > offers more system isolation. > > If I had my way, buildout would use virtualenv and throw away its > funny script generation. If virtualenv had existed before buildout Which one, the one provided to generate scripts from entry points with the *.egg recipes or the bin/buildout auto regeneration? > began development, probably things would have gone this way. I think > it would make the environment more pleasant for buildout users. Also * I don't think so, buildout is the only tool atm that permit to have really reproducible and isolated environments. Even, if you use the pip freezing machinery, it is not equivalent to buildout, Control! * Buildout can have single part to construct required eggs, at a specific version and let you control that. Pip will just search for this version, see that it's not available and fail. You have even recipes (like minitage.recipe.egg that permit to construct eggs with special version when you apply patches onto, thus, you can have the same egg in different flavors in the same eggs cache available for different projects. Those projects will just have to pin the right version to use, Control!. * Another thing is the "funny script generation", you have not one global site-packages for your project, but one global cache. But from this global cache, your scripts will only have available the eggs you declared, see Control! * Moreover buildout is not only a python packages manager, it's some of its recipes that permit to use it as. Buildout is just a great deployment tool that allow to script and manage your project in a "funny" and "flexible" way, Control! > I wish it used pip instead of its own installation procedure (based on > easy_install). I don't think the philosophical differences are that > great, and that it's more a matter of history -- because the code is And retro-compatibility. > written, there's not much incentive for buildout to remove that code > and rely on other libraries (virtualenv and pip). * Virtualenv is not really needed as buildout uses "eggs caches" and do the isolation from there. Scripts generate the adequate sys.path relying on the application requirements (which, once more, you are in total control). I prefer throught to use a virtualenv for each project (or a bunch of projects), and to bootstrap my buildouts from there. For me, they are complementary to achieve your deployment and isolation needs. > > -- > Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kiorky%40cryptelium.net -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Fri, Oct 9, 2009 at 3:22 AM, Ian Bicking wrote: > I'm coming in late and breaking threading, but wanted to reply to > Tarek's original email: > >> - easy_install is going to be deprecated ! use Pip ! > > Cool! I wouldn't have written pip if I didn't think it would improve > substantially on easy_install. > > Incidentally (because I know people get really enthused about this) > Carl Meyer just contributed a feature to pip to do atomic > uninstallation. Yes I saw that, it's great. And he is now involved in PEP 376 work so Pip could eventually become the first PEP 376 compliant installer/uninstaller. > > Someone mentioned that easy_install provided some things pip didn't; > outside of multi-versioned installs (which I'm not very enthusiastic > about) I'm not sure what this is? Basically what you've listed on Pip front page I think, like 'not tested under windows' But I don't see any blocking point besides some testing, to move from easy_install to pip, and the deprecation of multi-versioned feature seem to go in the direction of the community. >> - distribute.index: that's package_index and a few other things. >> everything required to interact with PyPI. We will promote >> its usage and see if Pip wants to use it as a basis. > > This is a little tricky. Primarily because there's a fair amount of > logic involved in the indexing (going around to different URLs, > parsing links, finding stuff). So long as there is logic, something > can go wrong -- often not in the package itself, but simple user error > (e.g., it doesn't look where the user thinks it should, or a link is > malformed, etc). Because of this, and as a general design goal of > pip, I want to show as much as I can about what it is doing and why. > This is primarily tied into pip's logging system (which is oriented > towards command-line output, and isn't the standard logging system). > Also it tracks *why* it got to a certain links. These are the two > things I can think of where the index code in pip is tied to pip, and > why it would be hard to use an external system. OK. Maybe this particular package could be used by another tool that needs to work with PyPI. It will also include a set of APIs that corresponds to PyPI XMLPRC services. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote: > > I know that the issue tracker for PyPI is (still) on SF, but > development appear to happen elsewhere and I can't find any > contact information on the PyPI web pages. Everything is provided here: http://wiki.python.org/moin/CheeseShopDev > > Is Richard Jones still working on it ? They I could contact him > directly to hash this out. I think Martin vL is the most active developer at this time. Regards Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
Tarek Ziadé wrote: > On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote: >> >> I know that the issue tracker for PyPI is (still) on SF, but >> development appear to happen elsewhere and I can't find any >> contact information on the PyPI web pages. > > Everything is provided here: > > http://wiki.python.org/moin/CheeseShopDev Thanks for the URL. >> >> Is Richard Jones still working on it ? They I could contact him >> directly to hash this out. > > I think Martin vL is the most active developer at this time. Ok, then I'll coordinate with Martin. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and so me words on Virtualenv, Pip)
Ian Bicking colorstudy.com> writes: > > Someone mentioned that easy_install provided some things pip didn't; > outside of multi-versioned installs (which I'm not very enthusiastic > about) I'm not sure what this is? http://pip.openplans.org/#differences-from-easy-install If it's obsolete the website should be updated... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Nick Coghlan wrote: > Christian Heimes wrote: >> The solution requires a new attribute in the sys module that contains >> the name of the implementation. As an alternative we could use the first >> field of sys.subversion but I prefer an explicit attribute. I'm >> proposing "sys.name" with a value of "CPython", "IronPython", "Jython" >> or "PyPy". > > My Google skills almost failed me, but searching for "sys.vm" found me > what I was after: http://bugs.python.org/issue4242 (a discussion > relating to a similar need in the context of flagging implementation > specific tests). Thanks, I knew about the discussion but I didn't know that somebody has already suggested a sys.vm attribute. > As mentioned in that discussion, as of Python 2.6, you can do the following: import platform platform.python_implementation() > 'CPython' > > (Although according to the function docstring, PyPy is currently missing > from the list of known implementations) > > Importing yet-another-module for use in site.py doesn't sound like a > great idea, so it may make sense to migrate that information into the > sys module is this approach is taken. "sys.name" is a little generic > though - something more explicit like "sys.vm" would be better. The platform modules uses additional modules like the re module. On my system "import platform" loads 7 additional module. The platform modul also uses multiple function calls and regular expression to detect the vm. I'm not going to blame the author of the function for the way the feature is implemented. It's the best way and I'd probably done it the same way, too. But it's an unnecessary slow down of every interpreter startup. 'sys.vm' it is. > Implementation specific user directories sound like a good idea indeed. > > An alternative to a lookup table approach might be to be a little more > direct and just retrieve the final part of the user specific directory > name directly from a new function in the sys module. Then different VM > authors can choose any directory name they want without CPython's > site.py needing to know anything else about them. I like your idea. It might be a better idea to turn sys.vm into a struct like sys.float_info. The struct can contains a set of required attributes like an id, a capitalized name, the platform (C, .NET, Java) and the suffix for the user site directory. >>> sys.vm sys.vm(id='cpython', name='CPython', platform='C', usersitesuffix='python26') # on win32: Python2.6 >>> sys.vm sys.vm(id='ironpython', name='IronPython', platform='.NET', usersitesuffix='ironpython26) # on win32: IronPython2.6 Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Christian Heimes cheimes.de> writes: > > >>> sys.vm > sys.vm(id='cpython', name='CPython', platform='C', > usersitesuffix='python26') # on win32: Python2.6 > > >>> sys.vm > sys.vm(id='ironpython', name='IronPython', platform='.NET', > usersitesuffix='ironpython26) # on win32: IronPython2.6 `usersitesuffix` should probably be a separate sys attribute, since it doesn't depend on the VM only, but also on the platform and version. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Tarek Ziadé wrote: > I have a suggestion though, that completes Nick's answer. > > distutils/command/install.py already contains install schemes and > imports USER_SITE and USER_BASE to builds user-specific install > schemes. I think it wouldn't hurt for clarity to reunite all these > schemes in a single place in the stdlib (so in sys maybe?) Hello Tarek! I'm feeling uncomfortable with sticking so much information into the sys module. Another module with installation schemata wouldn't hurt, though. In my opinion it's usually wise to separate configuration from logic. Christian PS: Thanks for your job with distribute! You are a life safer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Antoine Pitrou wrote: > `usersitesuffix` should probably be a separate sys attribute, since it doesn't > depend on the VM only, but also on the platform and version. I don't really care and I'm happy to follow the herd in this matter. :) Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Michael Foord wrote: > I really like this scheme. The important thing for IronPython is that we > can get it into Python 2.6 (along with other fixes to make distutils > compatible with IronPython - like not attempting to bytecode-compile > when sys.dont_write_bytecode is True). I don't think my proposal will land into 2.6. The changes are too severe for a bug fix release. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Christian Heimes wrote: > Nick Coghlan wrote: >> Importing yet-another-module for use in site.py doesn't sound like a >> great idea, so it may make sense to migrate that information into the >> sys module is this approach is taken. "sys.name" is a little generic >> though - something more explicit like "sys.vm" would be better. > > The platform modules uses additional modules like the re module. On my > system "import platform" loads 7 additional module. The platform modul > also uses multiple function calls and regular expression to detect the > vm. I'm not going to blame the author of the function for the way the > feature is implemented. It's the best way and I'd probably done it the > same way, too. But it's an unnecessary slow down of every interpreter > startup. 'sys.vm' it is. > >> Implementation specific user directories sound like a good idea indeed. >> >> An alternative to a lookup table approach might be to be a little more >> direct and just retrieve the final part of the user specific directory >> name directly from a new function in the sys module. Then different VM >> authors can choose any directory name they want without CPython's >> site.py needing to know anything else about them. > > > I like your idea. It might be a better idea to turn sys.vm into a struct > like sys.float_info. The struct can contains a set of required > attributes like an id, a capitalized name, the platform (C, .NET, Java) > and the suffix for the user site directory. > sys.vm > sys.vm(id='cpython', name='CPython', platform='C', > usersitesuffix='python26') # on win32: Python2.6 > sys.vm > sys.vm(id='ironpython', name='IronPython', platform='.NET', > usersitesuffix='ironpython26) # on win32: IronPython2.6 +1 on adding something like this, though, I'd use sys.python_implementation or just sys.implementation since not all Python implementations are virtual machines - many compile to machine code or some intermediate format. -1 on importing platform in site.py. Python's startup time is not great to begin with and this would cause the load time to increase even more. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
Christian Heimes wrote: Michael Foord wrote: I really like this scheme. The important thing for IronPython is that we can get it into Python 2.6 (along with other fixes to make distutils compatible with IronPython - like not attempting to bytecode-compile when sys.dont_write_bytecode is True). I don't think my proposal will land into 2.6. The changes are too severe for a bug fix release. Right, certainly not adding umpteen new sys attributes. :-) The problem is that the alternative implementations run well behind Python-trunk, indeed it doesn't really make sense for them to put a lot of effort into implementing a version that is still in development. The result is that they discover incompatibilites after a version has gone into 'bugfix only' mode. Whilst the fix you have described (add information to sys that is used by site.py and distutils) is ideal it can only go into 2.7. I would *still* like to see a fix in 2.6 - even if it is simple logic in site.py using sys.platform (if sys.platform == 'cli'; elif sys.platform == 'java' etc). That way IronPython 2.6 is able to be compatible with Python 2.6. This logic might need duplicating in distutils (I haven't looked at how distutils works out where the user site-packages folder is), but it is a 'maintenance only' fix. All the best, Michael Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
M.-A. Lemburg wrote: Christian Heimes wrote: Nick Coghlan wrote: Importing yet-another-module for use in site.py doesn't sound like a great idea, so it may make sense to migrate that information into the sys module is this approach is taken. "sys.name" is a little generic though - something more explicit like "sys.vm" would be better. The platform modules uses additional modules like the re module. On my system "import platform" loads 7 additional module. The platform modul also uses multiple function calls and regular expression to detect the vm. I'm not going to blame the author of the function for the way the feature is implemented. It's the best way and I'd probably done it the same way, too. But it's an unnecessary slow down of every interpreter startup. 'sys.vm' it is. Implementation specific user directories sound like a good idea indeed. An alternative to a lookup table approach might be to be a little more direct and just retrieve the final part of the user specific directory name directly from a new function in the sys module. Then different VM authors can choose any directory name they want without CPython's site.py needing to know anything else about them. I like your idea. It might be a better idea to turn sys.vm into a struct like sys.float_info. The struct can contains a set of required attributes like an id, a capitalized name, the platform (C, .NET, Java) and the suffix for the user site directory. sys.vm sys.vm(id='cpython', name='CPython', platform='C', usersitesuffix='python26') # on win32: Python2.6 sys.vm sys.vm(id='ironpython', name='IronPython', platform='.NET', usersitesuffix='ironpython26) # on win32: IronPython2.6 +1 on adding something like this, though, I'd use sys.python_implementation or just sys.implementation since not all Python implementations are virtual machines - many compile to machine code or some intermediate format. Agrred. -1 on importing platform in site.py. Python's startup time is not great to begin with and this would cause the load time to increase even more. Agrred. (And import time is even worse on IronPython.) Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
2009/10/9 Antoine Pitrou : > Ian Bicking colorstudy.com> writes: >> >> Someone mentioned that easy_install provided some things pip didn't; >> outside of multi-versioned installs (which I'm not very enthusiastic >> about) I'm not sure what this is? > > http://pip.openplans.org/#differences-from-easy-install > > If it's obsolete the website should be updated... Specifically, combine "only installs from source" with "might not work on Windows" and the result is pretty certainly unusable for C extensions on Windows. You can pretty much guarantee that the average user on Windows won't have a C compiler[1], and even if they do, they won't be able to carefully line up all the 3rd party C libraries needed to build some extensions. Binary packages are essential on Windows. Paul. [1] Heck, some extensions only build with mingw, others only build with MSVC. You need *two* compilers :-( ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Paul Moore wrote: 2009/10/9 Antoine Pitrou : Ian Bicking colorstudy.com> writes: Someone mentioned that easy_install provided some things pip didn't; outside of multi-versioned installs (which I'm not very enthusiastic about) I'm not sure what this is? http://pip.openplans.org/#differences-from-easy-install If it's obsolete the website should be updated... Specifically, combine "only installs from source" with "might not work on Windows" and the result is pretty certainly unusable for C extensions on Windows. You can pretty much guarantee that the average user on Windows won't have a C compiler[1], and even if they do, they won't be able to carefully line up all the 3rd party C libraries needed to build some extensions. Binary packages are essential on Windows. Definitely. Most Windows users won't have any compilers let alone 2. Michael Paul. [1] Heck, some extensions only build with mingw, others only build with MSVC. You need *two* compilers :-( ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
On 5 Oct, 01:04 pm, [email protected] wrote: On Mon, Oct 5, 2009 at 2:50 PM, wrote: Ned> Due to a change in distutils released with Python 2.6.3, packages Ned> that use setuptools (version 0.6c9, as of this writing), or the � �Ned> easy_install command, to build C extension modules fail ... � �... � �Ned> Among the packages known to be affected include lxml, Ned> zope-interface, jinja2, and, hence, packages dependent on these � �Ned> packages (e.g. sphinx, twisted, etc.). Maybe the Python test suite should include tests with a small number of widely used non-core packages like setuptools. I realize the pybots project exists to tackle this sort of stuff in greater detail. I'm thinking more of a smoke test than a comprehensive test suite covering all external packages. Setuptools is particularly important because so many extension authors use it. �If it breaks it implicitly breaks a lot of PyPI packages. I have created 6 months ago such a buildbot that downloads tarballs from the community, and run a few distutils commands on them, and make sure the result is similar in 2.6/2.7. and for "sdist" that the resulting tarball is similar. It was running over Twisted and Numpy, but has been discontinued because it was on my own server, where it was hard to keep it up (cpu/bandwidth) If the Snakebite project could host my buildbot (or at least slaves) or if the PSF could pay for a dedicated server for this, we would be able to trigger such warnings, and provide an e-mail service to package maintainers for example. The build could occur everytime Distutils *or* the project changes. If you want, until Snakebite is up, I can probably provide a slave which can at least do this testing for Twisted and perhaps some other projects. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BDFL pronouncement?
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.
Well, if this was the BDFL pronouncement that a lot of people have taken
it to be, does that allow Martin von Lewis to give the keys to
http://pypi.python.org/pypi/setuptools to the "distribute" developers,
so we can get on and use the original "setuptools" name without all the
confusion and hackery needed to make "distribute" work?
cheers,
Chris
PS: I had thought that MvL couldn't help because of ez_setup.py, but
it's only buildout that appears foolish enough to have a hardcoded
download of:
exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
).read() in ez
..and even that will keep working provided PJE doesn't take it down...
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
On Fri, Oct 9, 2009 at 5:01 PM, Chris Withers wrote: > Guido van Rossum wrote: >> >> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's >> Distribute is mature and in widespread use. IOW I support Tarek's fork >> and suggest nobody hold their breath waiting for setuptools 0.7. > > Well, if this was the BDFL pronouncement that a lot of people have taken it > to be, does that allow Martin von Lewis to give the keys to > http://pypi.python.org/pypi/setuptools to the "distribute" developers, so we > can get on and use the original "setuptools" name without all the confusion > and hackery needed to make "distribute" work? > I am -1 on this. At Python and PyPI level, 'Setuptools' is PJE's project and he's the one that manages the list of users that have extended rights on his project. In Distribute, our setup.py script makes sure setuptools is not in the way. It is explicit and documented, and there's a documentation explaining how to switch back to Setuptools. This exists only because there's no way yet in Python to say that a distribution can't run when another distribution is installed. But it's up to every project and developer to choose to switch to Distribute. And it's up to OS packagers to choose the best strategy at their levels when they package tools for their packaging system (so they pick one or the other and they are able to make a distinction between PJE python distribution and ours) Distribute developers will of course promote Distutils usage everywhere, but hijacking setuptools in PyPI would be a very bad thing imho. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] no consensus on static metadata
Tarek Ziadé wrote: == The fate of setup.py, and static metadata == So we are going to separate the metadata description from setup.py, in a static configuration file, that can be open and read by anyone without running any code. So we've worked on that lately in Distutils-SIG and came up with a micro-language, based on a ConfigParser file, that allows writing metadata fields that depends on sys.platform etc. I won't detail the syntax here but the idea is that the interpretation of this file can be done with a vanilla Python without running arbitrary code. I don't understand how the above two paragraphs are compatible. So I am adding this in Distutils for 2.7. NB: There was no consensus on this "micro-language" on distutils-sig. While I suspect I don't care as none of my packages rely on anything other than other python packages, others did care, and I found the syntax Tarek was proposing pretty clumsy. Does the PEP386 or the changes you're proposing for PEP314 cater for the extra_requires stuff in setuptools? I know I use that quite heavily and I'm not the only one... -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
Chris Withers simplistix.co.uk> writes: > > Well, if this was the BDFL pronouncement that a lot of people have taken > it to be, does that allow Martin von Lewis to give the keys to > http://pypi.python.org/pypi/setuptools to the "distribute" developers, > so we can get on and use the original "setuptools" name without all the > confusion and hackery needed to make "distribute" work? Er, perhaps this is a bit brutal? I don't think the BDFL has a right of life and death over third-party packages. I mean, we're an anarcho-syndicalist commune, aren't we? WOMAN: Who are the Britons? ARTHUR: Well, we all are. we're all Britons and I am your king. WOMAN: I didn't know we had a king. I thought we were an autonomous collective. DENNIS: You're fooling yourself. We're living in a dictatorship. A self-perpetuating autocracy in which the working classes-- [snip] Regards Antoine. PS : > PS: I had thought that MvL couldn't help because of ez_setup.py, but > it's only buildout that appears foolish enough to have a hardcoded > download of: Some projects also have an SVN "externals" pointing to the setuptools SVN repository, as described here: http://peak.telecommunity.com/doc/ez_setup/index.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute "upload_docs" command
Tarek Ziadé wrote: Some new commands are added there, when they are helpful and don't interact with the rest. I am thinking about "upload_docs" that let you upload documentation to PyPI. The goal is to move it to Distutils at some point, if the documentation feature of PyPI stays and starts to be used. This is already available: http://pypi.python.org/pypi/Sphinx-PyPI-upload How about helping the author of that extension make it work with Distribute or just get that implementation into Distutils core instead? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bits-of-Distribute naming
Tarek Ziadé wrote: - The code is splitted in many packages and might be distributed under several distributions. - distribute.resources: that's the old pkg_resources, but reorganized in clean, pep-8 modules. This package will only contain the query APIs and will focus on being PEP 376 compatible. We will promote its usage and see if Pip wants to use it as a basis. And maybe PyPM once it's open source ? ( ). It will probably shrink a lot though, once the stdlib provides PEP 376 support. Why not just call it pkg_resources and/or merge it with pkgutil to get it into the python stdlib? - distribute.entrypoints: that's the old pkg_resources entry points system, but on its own. it uses distribute.resources Why not get it into the core as distutils.entrypoints? That's where it belongs... - distribute.index: that's package_index and a few other things. everything required to interact with PyPI. We will promote its usage and see if Pip wants to use it as a basis. Why not call in "pypi.client" and "pypi.server" or, better yet, get it into the stdlib as disutils.index.client distutils.index.server? - distribute.core (might be renamed to main): that's everything else, and uses the other packages. ...which would be left, and could just be called "distribute". cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no consensus on static metadata
On Fri, Oct 9, 2009 at 5:32 PM, Chris Withers wrote: > >> So I am adding this in Distutils for 2.7. > > NB: There was no consensus on this "micro-language" on distutils-sig. > While I suspect I don't care as none of my packages rely on anything other > than other python packages, others did care, and I found the syntax Tarek > was proposing pretty clumsy. Please no bikeshedding again on the syntax. "consensus" doesn't mean that you agreed on the syntax. As I said to MAL, a PEP will be written with the precise syntax, and you will be able to make your voice heard on **Distutils-SIG**, even participate to it. But at the end, a syntax will be added. > Does the PEP386 or the changes you're proposing for PEP314 cater for the > extra_requires stuff in setuptools? I know I use that quite heavily and I'm > not the only one... Let's open a thread on Distutils-SIG about PEP 314 planned changes. Tarek. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supporting multiple versions of one package in one environment is insane
Tarek Ziadé wrote: = Virtualenv and the multiple version support in Distribute = (I am not saying "We" here because this part was not discussed yet with everyone) Good, so maybe take this discussion to distutils-sig first? Virtualenv allows you to create an isolated environment to install some distribution without polluting the main site-packages, a bit like a user site-packages. ...as does buildout, and these are the right type of solution to this problem. My opinion is that this tool exists only because Python doesn't support the installation of multiple versions for the same distributions. No, it exists because per-project specification of requirements is a really good thing. Having multiple versions of the same package in the same python environment it totally batshit crazy... Setuptools provided a multiple version support but I don't like its implementation and the way its works. See the "crazy" comment above... - a special import system using importlib that would automatically pick the latest version, thanks to PEP 376. As long as I never have to use it or see it, I don't really care, but this seems like creating more work for yourself and another gun pointed at the face, nevermind the foot, of the unwary newbie... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute "upload_docs" command
On Fri, Oct 9, 2009 at 5:37 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Some new commands are added there, when they are helpful and don't >> interact with the rest. I am thinking >> about "upload_docs" that let you upload documentation to PyPI. The >> goal is to move it to Distutils >> at some point, if the documentation feature of PyPI stays and starts to be >> used. > > This is already available: > > http://pypi.python.org/pypi/Sphinx-PyPI-upload > > How about helping the author of that extension make it work with Distribute > or just get that implementation into Distutils core instead? It's the case. The author is a Distribute commiter and *he* has added it in Distribute. PS: its' weird, it looks like your answers to the original thread are not belonging to the thread anymore. Is that my gmail or something on your mail client. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute "upload_docs" command
Tarek Ziadé wrote: How about helping the author of that extension make it work with Distribute or just get that implementation into Distutils core instead? It's the case. The author is a Distribute commiter and *he* has added it in Distribute. Great, but about just getting it into Distutils? I can't imagine it's that contentious... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bits-of-Distribute naming
On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> - The code is splitted in many packages and might be distributed under >> several distributions. >> >> - distribute.resources: that's the old pkg_resources... > Why not just call it pkg_resources and/or merge it with pkgutil to get it > into the python stdlib? Because "pkg_resources" belongs to 0.6 and we want 0.7 to be installable alongside 0.6 if needed. Now as I said earlier, this package might shrink once PEP 376 is finished, and have bits included in pkgutil. > >> - distribute.entrypoints: that's the old pkg_resources entry points >> system, but on its own. it uses distribute.resources > > Why not get it into the core as distutils.entrypoints? That's where it > belongs... What do you call 'core' ? distutils.core ? If yes, why does it belong to core ? entrypoint is a standalon plugin system . > >> - distribute.index: that's package_index and a few other things. >> everything required to interact with PyPI. We will promote >> its usage and see if Pip wants to use it as a basis. > > Why not call in "pypi.client" and "pypi.server" or, better yet, get it into > the stdlib as disutils.index.client distutils.index.server? We are keeping a "distribute." namespace for all bits. Now maybe one day it'll make it into Distutils, yes. But not now. Also, have a look at PEP 381 (mirroring infratructure for PyPI) In any case, the splitting is occuring *now* and is not written in the stone, so we can talk about this in Distutils-SIG, and improve it with your feedback. Regards, Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (10/02/09 - 10/09/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2444 open (+44) / 16471 closed (+14) / 18915 total (+58) Open issues with patches: 976 Average duration of open issues: 670 days. Median duration of open issues: 420 days. Open Issues Breakdown open 2410 (+44) pending33 ( +0) Issues Created Or Reopened (59) ___ traceback.format_exception_only does not return SyntaxError caro 10/07/09 http://bugs.python.org/issue6962reopened thewtex patch Doc/reference/datamodel: Slots description needs update 10/02/09 http://bugs.python.org/issue7036created Byron patch test_asynchat fails on os x 10.6 10/02/09 http://bugs.python.org/issue7037created chuck test_curses fails on os x 10.6 10/02/09 http://bugs.python.org/issue7038created chuck test_distutils fails on os x 10.610/02/09 CLOSED http://bugs.python.org/issue7039created chuck test_smtplib fails on os x 10.6 10/02/09 http://bugs.python.org/issue7040created chuck test_macostools fails on os x 10.6 10/02/09 http://bugs.python.org/issue7041created chuck test_signal fails on os x 10.6 10/02/09 http://bugs.python.org/issue7042created chuck patch test_urllib: constructLocalFileUrl returns invalid URLs on Windo 10/03/09 http://bugs.python.org/issue7043created srid urllib.urlopen crashes when used on Mac OS 10.6.1 through a prox 10/03/09 http://bugs.python.org/issue7044created jweber utf-8 encoding error 10/03/09 http://bugs.python.org/issue7045created ArcRiley decimal.py: use DivisionImpossible and DivisionUndefined 10/03/09 http://bugs.python.org/issue7046created skrah decimal.py: NaN payload conversion 10/03/09 CLOSED http://bugs.python.org/issue7047created skrah decimal.py: logb: round the result if it is greater than prec10/03/09 http://bugs.python.org/issue7048created skrah patch decimal.py: NaN result in pow(x, y, z) with prec 1 10/03/09 http://bugs.python.org/issue7049created skrah patch Augmented assignment of tuple crashes IDLE 10/03/09 CLOSED http://bugs.python.org/issue7050created mfitz 'g'/'G' format docs need a little more explanation 10/03/09 http://bugs.python.org/issue7051created benjamin.peterson "from logging import *" causes an error under Ubuntu Karmic 10/04/09 CLOSED http://bugs.python.org/issue7052created vak wrong overload of slot wrapper 10/04/09 CLOSED http://bugs.python.org/issue7053created omatt
Re: [Python-Dev] Bits-of-Distribute naming
Tarek Ziadé wrote: - distribute.entrypoints: that's the old pkg_resources entry points system, but on its own. it uses distribute.resources Why not get it into the core as distutils.entrypoints? That's where it belongs... What do you call 'core' ? distutils.core ? Sorry, mean stdlib. distutils.entrypoints would seem to be the sensible place. - distribute.index: that's package_index and a few other things. everything required to interact with PyPI. We will promote its usage and see if Pip wants to use it as a basis. Why not call in "pypi.client" and "pypi.server" or, better yet, get it into the stdlib as disutils.index.client distutils.index.server? We are keeping a "distribute." namespace for all bits. Why? In any case, the splitting is occuring *now* and is not written in the stone, so we can talk about this in Distutils-SIG, and improve it with your feedback. Shame there hasn't been any discussion of this recently on distutils-sig... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute "upload_docs" command
On Fri, Oct 9, 2009 at 6:03 PM, Chris Withers wrote: > Tarek Ziadé wrote: >>> >>> How about helping the author of that extension make it work with >>> Distribute >>> or just get that implementation into Distutils core instead? >> >> It's the case. The author is a Distribute commiter and *he* has added >> it in Distribute. > > Great, but about just getting it into Distutils? I can't imagine it's that > contentious... This PyPI feature is pretty new. It's great to have the client command on Distribute. If its usage spreads it'll make it to Distutils. If you want to see it included Distutils (I do too) help us promoting its usage Tarek. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute "upload_docs" command
Tarek Ziadé wrote: This PyPI feature is pretty new. It's great to have the client command on Distribute. If its usage spreads it'll make it to Distutils. If you want to see it included Distutils (I do too) help us promoting its usage The only thing that discourages me from using the PyPI docs feature is that it only allows documentation per-distribution, not per-version-per-distribution. While you can work around this by building docs for all versions and putting them in one .zip file, that seems like a hack. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bits-of-Distribute naming
On Fri, Oct 9, 2009 at 6:08 PM, Chris Withers wrote: > > Shame there hasn't been any discussion of this recently on distutils-sig... We had many discussion on this already. I don't mind to have another round, on the contrary, but let's do it in Distutils-SIG We are making a lot of noise now in Python-dev, which is not required Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no consensus on static metadata
Tarek Ziadé wrote: NB: There was no consensus on this "micro-language" on distutils-sig. While I suspect I don't care as none of my packages rely on anything other than other python packages, others did care, and I found the syntax Tarek was proposing pretty clumsy. Please no bikeshedding again on the syntax. Tarek, throwing "bikeshedding" at an important syntactical discussion like this is verging on rude. Please stop it and accept that the best solution has not been found yet. As I said to MAL, a PEP will be written with the precise syntax, and you will be able to make your voice heard on **Distutils-SIG**, even participate to it. Great. Does the PEP386 or the changes you're proposing for PEP314 cater for the extra_requires stuff in setuptools? I know I use that quite heavily and I'm not the only one... Let's open a thread on Distutils-SIG about PEP 314 planned changes. OK, look forward to reading it and commenting. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Fri, Oct 9, 2009 at 3:54 AM, kiorky wrote: >> If I had my way, buildout would use virtualenv and throw away its >> funny script generation. If virtualenv had existed before buildout > > Which one, the one provided to generate scripts from entry points with the > *.egg > recipes or the bin/buildout auto regeneration? Well, if multi-versioned installs were deprecated, it would not be necessary to use Setuptools' style of script generation. Instead you could simply dereference the entry point, calling the underlying function directly in the script. This detail is probably more of a distutils-sig question, and I don't have a strong opinion. But I was thinking specifically of the egg activation buildout puts at the top of scripts. >> began development, probably things would have gone this way. I think >> it would make the environment more pleasant for buildout users. Also > > * I don't think so, buildout is the only tool atm that permit to have really > reproducible and isolated environments. Even, if you use the pip freezing > machinery, it is not equivalent to buildout, Control! I believe that to fully insulate buildout you need still virtualenv --no-site-packages. But I'm not arguing that virtualenv/pip makes buildout obsolete, only that they have overlapping functionality, and I think buildout would benefit from making use of that overlap. > * Buildout can have single part to construct required eggs, at a specific > version and let you control that. Pip will just search for this version, see > that it's not available and fail. You have even recipes (like > minitage.recipe.egg that permit to construct eggs with special version when > you > apply patches onto, thus, you can have the same egg in different flavors in > the > same eggs cache available for different projects. Those projects will just > have > to pin the right version to use, Control!. In my own work I use multiple virtualenv environments for this use case, to similar effect. pip of course is not a generalized build tool, but then minitage.recipe.egg is not the main egg installer either. > * Another thing is the "funny script generation", you have not one global > site-packages for your project, but one global cache. But from this global > cache, your scripts will only have available the eggs you declared, see > Control! > * Moreover buildout is not only a python packages manager, it's some of its > recipes that permit to use it as. Buildout is just a great deployment tool > that > allow to script and manage your project in a "funny" and "flexible" way, > Control! Sure; I'm just advocating that buildout more explicitly use some of the functionality of virtualenv/pip (which may require some more features in those tools, but I'm open to that). But specific discussion of this would probably be more appropriate on distutils-sig. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
Tarek Ziadé wrote: At Python and PyPI level, 'Setuptools' is PJE's project and he's the one that manages the list of users that have extended rights on his project. Indeed, if only he would see sense :-( In Distribute, our setup.py script makes sure setuptools is not in the way. It is explicit and documented, and there's a documentation explaining how to switch back to Setuptools. It's a hack though... This exists only because there's no way yet in Python to say that a distribution can't run when another distribution is installed. I don't this should ever be needed, except in this edge case caused by one man's stubbornness... Distribute developers will of course promote Distutils usage everywhere, but hijacking setuptools in PyPI would be a very bad thing imho. *sigh* I don't see it as hijacking, provided Guido is making a BDFL pronouncement that you're maintaining this software and PJE finally sees sense and accepts that. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supporting multiple versions of one package in one environment is insane
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote: > Tarek Ziadé wrote: >> Virtualenv allows you to create an isolated environment to install >> some distribution without polluting the >> main site-packages, a bit like a user site-packages. > > ...as does buildout, and these are the right type of solution to this > problem. > where type of problem == sandboxed environment, sure. How do you solve the problem for system packagers? -Toshio pgpIuAAzlNOuB.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore wrote: > 2009/10/9 Antoine Pitrou : >> Ian Bicking colorstudy.com> writes: >>> >>> Someone mentioned that easy_install provided some things pip didn't; >>> outside of multi-versioned installs (which I'm not very enthusiastic >>> about) I'm not sure what this is? >> >> http://pip.openplans.org/#differences-from-easy-install >> >> If it's obsolete the website should be updated... > > Specifically, combine "only installs from source" with "might not work > on Windows" and the result is pretty certainly unusable for C > extensions on Windows. You can pretty much guarantee that the average > user on Windows won't have a C compiler[1], and even if they do, they > won't be able to carefully line up all the 3rd party C libraries > needed to build some extensions. > > Binary packages are essential on Windows. I'll admit I have some blindness when it comes to Windows. I agree binary installation on Windows is important. (I don't think it's very important on other platforms, or at least not very effective in easy_install so it wouldn't be a regression.) I note some other differences in that document: > It cannot install from eggs. It only installs from source. (Maybe this will > be changed sometime, but it’s low priority.) Outside of binaries on Windows, I'm still unsure if installing eggs serves a useful purpose. I'm not sure if eggs are any better than wininst binaries either...? > It doesn’t understand Setuptools extras (like package[test]). This should be > added eventually. I haven't really seen Setuptools' extras used effectively, so I'm unsure if it's a useful feature. I understand the motivation for extras, but motivated features aren't necessarily useful features. > It is incompatible with some packages that customize distutils or setuptools > in their setup.py files. I don't have a solution for this, and generally easy_install does not perform much better than pip in these cases. Work in Distribute hopefully will apply to this issue. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
I'm crossposting to continue on distutils. Ian Bicking a écrit : > On Fri, Oct 9, 2009 at 3:54 AM, kiorky wrote: > Well, if multi-versioned installs were deprecated, it would not be > necessary to use Setuptools' style of script generation. Instead you > could simply dereference the entry point, calling the underlying > function directly in the script. This detail is probably more of a > distutils-sig question, and I don't have a strong opinion. > > But I was thinking specifically of the egg activation buildout puts at > the top of scripts. The egg activation is just the result of the constructed working set, which aggregates all the python packages that fulfill the options inputed by the user. The only needed packages and nothing else or more. >>> began development, probably things would have gone this way. I think >>> it would make the environment more pleasant for buildout users. Also >> * I don't think so, buildout is the only tool atm that permit to have really >> reproducible and isolated environments. Even, if you use the pip freezing >> machinery, it is not equivalent to buildout, Control! > > I believe that to fully insulate buildout you need still virtualenv > --no-site-packages. But I'm not arguing that virtualenv/pip makes Right, I do so, but i also drop nothing in that virtualenv site-packages. > buildout obsolete, only that they have overlapping functionality, and > I think buildout would benefit from making use of that overlap. recipes have more features and are another way to do, complementary or not. (patching, compiling options, pinning version). You have also more control on what is installed/used/shared with buildout than with the others. >> * Buildout can have single part to construct required eggs, at a specific >> version and let you control that. Pip will just search for this version, see >> that it's not available and fail. You have even recipes (like >> minitage.recipe.egg that permit to construct eggs with special version when >> you >> apply patches onto, thus, you can have the same egg in different flavors in >> the >> same eggs cache available for different projects. Those projects will just >> have >> to pin the right version to use, Control!. > > In my own work I use multiple virtualenv environments for this use > case, to similar effect. pip of course is not a generalized build > tool, but then minitage.recipe.egg is not the main egg installer > either. *.recipe.egg can use caches to avoid duplications among many projects environments. You setup seems to duplicate stuff around. >> * Another thing is the "funny script generation", you have not one global >> site-packages for your project, but one global cache. But from this global >> cache, your scripts will only have available the eggs you declared, see >> Control! >> * Moreover buildout is not only a python packages manager, it's some of its >> recipes that permit to use it as. Buildout is just a great deployment tool >> that >> allow to script and manage your project in a "funny" and "flexible" way, >> Control! > > Sure; I'm just advocating that buildout more explicitly use some of > the functionality of virtualenv/pip (which may require some more > features in those tools, but I'm open to that). But specific > discussion of this would probably be more appropriate on > distutils-sig. > -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supporting multiple versions of one package in one environment is insane
Toshio Kuratomi wrote: On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote: Tarek Ziadé wrote: Virtualenv allows you to create an isolated environment to install some distribution without polluting the main site-packages, a bit like a user site-packages. ...as does buildout, and these are the right type of solution to this problem. where type of problem == sandboxed environment, sure. How do you solve the problem for system packagers? What's to stop a system packager either just running the buildout on install, or running the buildout at package build time and then just dropping the resulting environment wherever they want to install applications? Such a package would only be dependent on the right python version at runtime... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Ian Bicking wrote: On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore wrote: 2009/10/9 Antoine Pitrou : Ian Bicking colorstudy.com> writes: Someone mentioned that easy_install provided some things pip didn't; outside of multi-versioned installs (which I'm not very enthusiastic about) I'm not sure what this is? http://pip.openplans.org/#differences-from-easy-install If it's obsolete the website should be updated... Specifically, combine "only installs from source" with "might not work on Windows" and the result is pretty certainly unusable for C extensions on Windows. You can pretty much guarantee that the average user on Windows won't have a C compiler[1], and even if they do, they won't be able to carefully line up all the 3rd party C libraries needed to build some extensions. Binary packages are essential on Windows. I'll admit I have some blindness when it comes to Windows. I agree binary installation on Windows is important. (I don't think it's very important on other platforms, or at least not very effective in easy_install so it wouldn't be a regression.) I note some other differences in that document: It cannot install from eggs. It only installs from source. (Maybe this will be changed sometime, but it’s low priority.) Outside of binaries on Windows, I'm still unsure if installing eggs serves a useful purpose. I'm not sure if eggs are any better than wininst binaries either...? Many Windows users would be quite happy if the standard mechanism for installing non-source distributions on Windows was via the wininst binaries. I wonder if it is going to be possible to make this compatible with the upcoming distutils package management 'stuff' (querying for installed packages, uninstallation etc) since installation/uninstallation goes through the Windows system package management feature. I guess it would be eminently possible but require some reasonably high level Windows-fu to do. Michael It doesn’t understand Setuptools extras (like package[test]). This should be added eventually. I haven't really seen Setuptools' extras used effectively, so I'm unsure if it's a useful feature. I understand the motivation for extras, but motivated features aren't necessarily useful features. It is incompatible with some packages that customize distutils or setuptools in their setup.py files. I don't have a solution for this, and generally easy_install does not perform much better than pip in these cases. Work in Distribute hopefully will apply to this issue. -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Probably all these discussions are better on distutils-sig (just copying python-dev to note the movement of the discussion) On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord wrote: >> Outside of binaries on Windows, I'm still unsure if installing eggs >> serves a useful purpose. I'm not sure if eggs are any better than >> wininst binaries either...? > > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. > > I wonder if it is going to be possible to make this compatible with the > upcoming distutils package management 'stuff' (querying for installed > packages, uninstallation etc) since installation/uninstallation goes through > the Windows system package management feature. I guess it would be > eminently possible but require some reasonably high level Windows-fu to do. As far as pip works, it unpacks a package and runs "python setup.py install (and some options that aren't that interesting, but are provided specifically by setuptools)". Well, it's slightly more complicated, but more to the point it doesn't install in-process or dictate how setup.py works, except that it takes some specific options. Running a Windows installer in the same way would be fine, in that sense. Alternately pip could unpack the wininst zip file and install it directly; I'm not sure if that would be better or worse? If wininst uses the central package manager of the OS then certain features (like virtualenv, PYTHONHOME, --prefix, etc) would not be possible. For Distribute (or Setuptools or by association pip) to see that a package is installed, it must have the appropriate metadata. For Setuptools (and Distribute 0.6) this is a directory or file, on sys.path, "Package.egg-info" (or in Package-X.Y.egg/EGG-INFO). If a file, it should be a PKG-INFO file, if a directory it should contain a PKG-INFO file. So however the package gets installed, if that metadata is installed then it can be queried. I don't think querying the Windows system package management would be necessary or desirable. Nobody is trying that with deb/rpm either. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
Chris Withers simplistix.co.uk> writes: > > *sigh* I don't see it as hijacking, provided Guido is making a BDFL > pronouncement that you're maintaining this software Well, what you are proposing *is* hijacking. PJE is not paid or employed by Guido, he is the full author of setuptools. Forking is of course fine (this is free software), but saying "I overthrow you as the maintainer of this software" is not. While you (and I) may be unsatisfied with PJE's maintenance style, personal (dis)affection should not be what motivates our decisions. A piece of software has an author who has some moral rights on it, and should be treated with respect. After all, when an author decides to release code under a free license, it shows a fair amount of trust and respect towards the user; it is only fair that the user shows the same amount of trust and respect (*). (*) it has happened that some users don't, and in that case the author's reaction can be violent. For example, Nessus became proprietary: http://news.cnet.com/Nessus-security-tool-closes-its-source/2100-7344_3-5890093.html Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
On Fri, Oct 9, 2009 at 04:53, Michael Foord wrote: > Christian Heimes wrote: > >> Michael Foord wrote: >> >> >>> I really like this scheme. The important thing for IronPython is that we >>> can get it into Python 2.6 (along with other fixes to make distutils >>> compatible with IronPython - like not attempting to bytecode-compile when >>> sys.dont_write_bytecode is True). >>> >>> >> >> I don't think my proposal will land into 2.6. The changes are too severe >> for a bug fix release. >> >> > > Right, certainly not adding umpteen new sys attributes. :-) > > The problem is that the alternative implementations run well behind > Python-trunk, indeed it doesn't really make sense for them to put a lot of > effort into implementing a version that is still in development. The result > is that they discover incompatibilites after a version has gone into 'bugfix > only' mode. > > Whilst the fix you have described (add information to sys that is used by > site.py and distutils) is ideal it can only go into 2.7. I would *still* > like to see a fix in 2.6 - even if it is simple logic in site.py using > sys.platform (if sys.platform == 'cli'; elif sys.platform == 'java' etc). > That way IronPython 2.6 is able to be compatible with Python 2.6. This logic > might need duplicating in distutils (I haven't looked at how distutils works > out where the user site-packages folder is), but it is a 'maintenance only' > fix. > But it's still a change in semantics. Tossing this into 2.6 would mean that anyone who has worked around the current behaviour is going to have a busted install. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
On Fri, Oct 9, 2009 at 10:57, Antoine Pitrou wrote: > Chris Withers simplistix.co.uk> writes: > > > > *sigh* I don't see it as hijacking, provided Guido is making a BDFL > > pronouncement that you're maintaining this software > > Well, what you are proposing *is* hijacking. PJE is not paid or employed by > Guido, he is the full author of setuptools. Forking is of course fine (this > is > free software), but saying "I overthrow you as the maintainer of this > software" > is not. > > While you (and I) may be unsatisfied with PJE's maintenance style, personal > (dis)affection should not be what motivates our decisions. A piece of > software > has an author who has some moral rights on it, and should be treated with > respect. After all, when an author decides to release code under a free > license, > it shows a fair amount of trust and respect towards the user; it is only > fair > that the user shows the same amount of trust and respect (*). > FWIW I agree with Antoine. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bits-of-Distribute naming
2009/10/9 Chris Withers : > Why not get it into the core as distutils.entrypoints? That's where it > belongs... Well, one reason is that it can't be distributed separately under that name, and hence not be tested separately or bugfixed separately. Rule #1 for inclusion in the standard library is that the module pretty much is dead, and that you don't need new releases or new features. This isn't true for any part of a refactored setuptools. We will need to distribute most of this separately for a while first. That means that distutils.anything doesn't work. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
The *only* change in semantics I'm proposing is for users of IronPython 2.6 which is not even at final release yet. CPython users would be unaffected. Sorry for top-posting, mobile device. Michael -- http://www.ironpythoninaction.com On 9 Oct 2009, at 19:00, Brett Cannon wrote: On Fri, Oct 9, 2009 at 04:53, Michael Foord wrote: Christian Heimes wrote: Michael Foord wrote: I really like this scheme. The important thing for IronPython is that we can get it into Python 2.6 (along with other fixes to make distutils compatible with IronPython - like not attempting to bytecode-compile when sys.dont_write_bytecode is True). I don't think my proposal will land into 2.6. The changes are too severe for a bug fix release. Right, certainly not adding umpteen new sys attributes. :-) The problem is that the alternative implementations run well behind Python-trunk, indeed it doesn't really make sense for them to put a lot of effort into implementing a version that is still in development. The result is that they discover incompatibilites after a version has gone into 'bugfix only' mode. Whilst the fix you have described (add information to sys that is used by site.py and distutils) is ideal it can only go into 2.7. I would *still* like to see a fix in 2.6 - even if it is simple logic in site.py using sys.platform (if sys.platform == 'cli'; elif sys.platform == 'java' etc). That way IronPython 2.6 is able to be compatible with Python 2.6. This logic might need duplicating in distutils (I haven't looked at how distutils works out where the user site-packages folder is), but it is a 'maintenance only' fix. But it's still a change in semantics. Tossing this into 2.6 would mean that anyone who has worked around the current behaviour is going to have a busted install. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote: > The *only* change in semantics I'm proposing is for users of IronPython 2.6 > which is not even at final release yet. CPython users would be unaffected. > > Then why can't IronPython patch site.py to do what they want? I still feel uncomfortable changing site.py for this in a micro release. > Sorry for top-posting, mobile device. > > Aahz was the most adamant hater of top-posting and he isn't subscribed to python-dev anymore, so whatever. -Brett > Michael > > > -- > http://www.ironpythoninaction.com > > On 9 Oct 2009, at 19:00, Brett Cannon wrote: > > > > On Fri, Oct 9, 2009 at 04:53, Michael Foord < > [email protected]> wrote: > >> Christian Heimes wrote: >> >>> Michael Foord wrote: >>> >>> I really like this scheme. The important thing for IronPython is that we can get it into Python 2.6 (along with other fixes to make distutils compatible with IronPython - like not attempting to bytecode-compile when sys.dont_write_bytecode is True). >>> >>> I don't think my proposal will land into 2.6. The changes are too severe >>> for a bug fix release. >>> >>> >> >> Right, certainly not adding umpteen new sys attributes. :-) >> >> The problem is that the alternative implementations run well behind >> Python-trunk, indeed it doesn't really make sense for them to put a lot of >> effort into implementing a version that is still in development. The result >> is that they discover incompatibilites after a version has gone into 'bugfix >> only' mode. >> >> Whilst the fix you have described (add information to sys that is used by >> site.py and distutils) is ideal it can only go into 2.7. I would *still* >> like to see a fix in 2.6 - even if it is simple logic in site.py using >> sys.platform (if sys.platform == 'cli'; elif sys.platform == 'java' etc). >> That way IronPython 2.6 is able to be compatible with Python 2.6. This logic >> might need duplicating in distutils (I haven't looked at how distutils works >> out where the user site-packages folder is), but it is a 'maintenance only' >> fix. >> > > But it's still a change in semantics. Tossing this into 2.6 would mean that > anyone who has worked around the current behaviour is going to have a busted > install. > > -Brett > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 and IronPython
On Thu, Oct 8, 2009 at 7:17 AM, Christian Heimes wrote: > CPython: > ~/.local/lib/python2.6/site-packages > %APPDATA%/Python/Python26 > > IronPython: > ~/.local/lib/ironpython2.6/site-packages > %APPDATA%/Python/IronPython26 > > Jython: > ~/.local/lib/jython2.6/site-packages > %APPDATA%/Python/Jython26 I like this too! Jython has yet to seriously start on 2.6, but when we do, would it help if Jython's sys.version grew a "Jython" in a similar place as IronPython? It would look something like: >>>sys.version '2.6.0 (Jython trunk:6849M, Oct 9 2009, 14:19:04) \n[Java HotSpot(TM) Client VM (Apple Inc.)]' -Frank ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] supporting multiple versions of one package in one environment is insane
On Fri, Oct 09, 2009 at 05:29:28PM +0100, Chris Withers wrote: > Toshio Kuratomi wrote: >> On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote: >>> Tarek Ziadé wrote: Virtualenv allows you to create an isolated environment to install some distribution without polluting the main site-packages, a bit like a user site-packages. >>> ...as does buildout, and these are the right type of solution to >>> this problem. >>> >> where type of problem == sandboxed environment, sure. How do you solve the >> problem for system packagers? > > What's to stop a system packager either just running the buildout on > install, or running the buildout at package build time and then just > dropping the resulting environment wherever they want to install > applications? Such a package would only be dependent on the right python > version at runtime... > If buildout creates sandboxed environments like virtualenv then everything here applies: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries You can also listen/watch the talk I gave at PyCon which is linked from that page: http://pycon.blip.tv/file/2072580/ If it doesn't create sandboxed environments, then you'll need to give me about a paragraph explaining what it does do. -Toshio pgpWXyj4ioW6W.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no consensus on static metadata
Chris Withers schrieb: > Tarek Ziadé wrote: >>> NB: There was no consensus on this "micro-language" on distutils-sig. >>> While I suspect I don't care as none of my packages rely on anything other >>> than other python packages, others did care, and I found the syntax Tarek >>> was proposing pretty clumsy. >> >> Please no bikeshedding again on the syntax. > > Tarek, throwing "bikeshedding" at an important syntactical discussion > like this is verging on rude. Please stop it and accept that the best > solution has not been found yet. At some point a decision must be made, and it will be made by Tarek as the "main packaging guy" (don't want to throw "dictator" around again). For syntax, there often is no such thing as "the best solution". Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
Chris Withers schrieb: > Guido van Rossum wrote: >> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's >> Distribute is mature and in widespread use. IOW I support Tarek's fork >> and suggest nobody hold their breath waiting for setuptools 0.7. > > Well, if this was the BDFL pronouncement that a lot of people have taken > it to be, does that allow Martin von Lewis to give the keys to > http://pypi.python.org/pypi/setuptools to the "distribute" developers, > so we can get on and use the original "setuptools" name without all the > confusion and hackery needed to make "distribute" work? That's absurd. There's a certain area where Guido can make pronouncements, but third-party packages is not it. Even if they're hosted on python.org infrastructure. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl wrote: > Chris Withers schrieb: >> Guido van Rossum wrote: >>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's >>> Distribute is mature and in widespread use. IOW I support Tarek's fork >>> and suggest nobody hold their breath waiting for setuptools 0.7. >> >> Well, if this was the BDFL pronouncement that a lot of people have taken >> it to be, does that allow Martin von Lewis to give the keys to >> http://pypi.python.org/pypi/setuptools to the "distribute" developers, >> so we can get on and use the original "setuptools" name without all the >> confusion and hackery needed to make "distribute" work? > > That's absurd. There's a certain area where Guido can make pronouncements, > but third-party packages is not it. Even if they're hosted on python.org > infrastructure. Right. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
On Fri, Oct 09, 2009 at 01:56:42PM -0700, Guido van Rossum wrote: > On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl wrote: > > Chris Withers schrieb: > >> Guido van Rossum wrote: > >>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's > >>> Distribute is mature and in widespread use. IOW I support Tarek's fork > >>> and suggest nobody hold their breath waiting for setuptools 0.7. > >> > >> Well, if this was the BDFL pronouncement that a lot of people have taken > >> it to be, does that allow Martin von Lewis to give the keys to > >> http://pypi.python.org/pypi/setuptools to the "distribute" developers, > >> so we can get on and use the original "setuptools" name without all the > >> confusion and hackery needed to make "distribute" work? > > > > That's absurd. ?There's a certain area where Guido can make pronouncements, > > but third-party packages is not it. ?Even if they're hosted on python.org > > infrastructure. > > Right. Is that a pronouncement? :) "GvR, the self-limiting BDFL." --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Howto handle multilib conflict?
Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237 yum install libotf-devel.i586 libotf-devel.x86_64 yields: Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 What is the recommended way to resolve this? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Howto handle multilib conflict?
Sorry, sent to wrong list! Please ignore. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL pronouncement?
>> That's absurd. There's a certain area where Guido can make >> pronouncements, but third-party packages is not it. Even if they're >> hosted on python.org infrastructure. Guido> Right. Now if you were the un-BDFL you could step in here. ;-) This whole topic seems to have a lot of people fairly agitated, so clearly it's important to a significant subset of the Python development community. Might I suggest taking this off python-dev for awhile though? I seem to recall a similar suggestion a couple days ago to take it to distutils-sig or python-ideas, but that seems to have been ignored.) I mostly tuned the entire thread out until I saw that Guido had joined in the fray (sort of). Maybe since I don't distribute a lot of Python packages it's not as important to me. Let me know when you've solved the problem. I trust you. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP about sys.implementation and implementation specific user site directory
Fellow Python developers! In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next weeks. Before I start with the PEP I like to reach consensus over the goal. Alternative implementations of our beloved programming languages are becoming more important every day. Although IronPython, Jython and PyPy are trying hard to get as compatible to CPython as possible there are numerous reasons for conditional code. General Python unit tests vs. CPython specific unit tests are one reasons, implementation specific module search paths are another. At the moment Python has no easy way to inspect the implementation besides some code in the platform module. I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix. sys.implementation -- (Proposed by Nick, MAL and others.) sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness. id (required): lower case identifier, for example "cpython", "ironpython", "jython", "pypy" name (required): mixed case name of the implementation, for example "CPython", "IronPython", "Jython", "PyPy" platform (required): platform or language of the implementation, for example "C", ".NET", "Java" runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net" compiler (required): verbose name of the compiler, for example "GCC 4.3.3", "Java HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" ... sys.userdirsuffix - sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python. Examples: python2.6 (CPython, Unix) Python26 (CPython, Windows) ironpython2.6 (IronPython, Unix) IronPython26 (IronPython, Windows) ... Comments? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Christian wrote: > sys.implementation is a PyStructSequence that contains various > information about the current implementation. Some fields are required > to be present on every implementation. Implementations may choose to > add > additional fields as they see fit. Some fields like compiler are useful > for introspection and are already part of sys.version. I like to > include > them for the sake of completeness. Given that this is all about establishing some common ground between implementations I would propose not using a CPython specific term here such as PyStructSequence :) The Python docs seem to use structseq for sys.float_info. > compiler (required): > verbose name of the compiler, for example "GCC 4.3.3", "Java > HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" What's the value of this attribute? The main reason I ask is there's no way that I know of to determine the JIT being used in .NET. We could of course fill in some dummy value here for IronPython but I'm also not sure why anyone would use this. Otherwise it looks good to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
2009/10/9 Christian Heimes : > Fellow Python developers! > > In the light of our recent discussion about implementation specific > information and user site directory I like to start a new PEP. Much to > my regret I wasn't able to contribute to Python core development over > the past months. I hope I can find some free time over the next weeks. Glad to have you back! > > Before I start with the PEP I like to reach consensus over the goal. > Alternative implementations of our beloved programming languages are > becoming more important every day. Although IronPython, Jython and PyPy > are trying hard to get as compatible to CPython as possible there are > numerous reasons for conditional code. General Python unit tests vs. > CPython specific unit tests are one reasons, implementation specific > module search paths are another. At the moment Python has no easy way to > inspect the implementation besides some code in the platform module. > > I'm proposing two new attributes in the sys module: sys.implementation > and sys.userdirsuffix. Overall, +1. > > sys.implementation > -- > > (Proposed by Nick, MAL and others.) > > sys.implementation is a PyStructSequence that contains various > information about the current implementation. Some fields are required > to be present on every implementation. Implementations may choose to add > additional fields as they see fit. Some fields like compiler are useful > for introspection and are already part of sys.version. I like to include > them for the sake of completeness. Can we generate sys.version from sys.implementation then? > > id (required): > lower case identifier, for example "cpython", "ironpython", "jython", > "pypy" > > name (required): > mixed case name of the implementation, for example "CPython", > "IronPython", "Jython", "PyPy" > > platform (required): > platform or language of the implementation, for example "C", ".NET", > "Java" > > runtime (required): > lower case runtime library of the implementation, for example "libc", > "msvcrt90", "java6", ".net" > > compiler (required): > verbose name of the compiler, for example "GCC 4.3.3", "Java > HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" > > ... > > > sys.userdirsuffix > - Why not site.userdirsuffix? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Benjamin Peterson wrote: >> sys.implementation is a PyStructSequence that contains various >> information about the current implementation. Some fields are required >> to be present on every implementation. Implementations may choose to add >> additional fields as they see fit. Some fields like compiler are useful >> for introspection and are already part of sys.version. I like to include >> them for the sake of completeness. > > Can we generate sys.version from sys.implementation then? sys.version is created by Py_GetVersion() which uses Py_GetCompiler() for the compiler information: PyOS_snprintf(version, sizeof(version), "%.80s (%.80s) %.80s", PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler()); For CPython the compiler attribute should be set to the return value of Py_GetCompiler(). >> sys.userdirsuffix >> - > > Why not site.userdirsuffix? Because all implementations of Python like to use the same, unpatched site module. The sys module is different for every implementation. It's more convenient to have an attribute on the sys module that can be filled by each implementation. I could also add a lookup table for all known implementations to the site module. But what about unknown or new implementations? They would have to wait until we add a new entry for them. The sys.userdirsuffix is more flexible and future prove. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] eggs now mandatory for pypi?
> I know that the issue tracker for PyPI is (still) on SF, but > development appear to happen elsewhere and I can't find any > contact information on the PyPI web pages. PyPI discussion takes place mostly on catalog-sig. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
2009/10/9 Christian Heimes : > Benjamin Peterson wrote: >>> sys.userdirsuffix >>> - >> >> Why not site.userdirsuffix? > > Because all implementations of Python like to use the same, unpatched > site module. The sys module is different for every implementation. It's > more convenient to have an attribute on the sys module that can be > filled by each implementation. I could also add a lookup table for all > known implementations to the site module. But what about unknown or new > implementations? They would have to wait until we add a new entry for > them. The sys.userdirsuffix is more flexible and future prove. I think we should make a semi-private (public to the stdlib) module like _sys or _implementation part of the Python VM API. Then, instead of stuffing everything into sys, we can provide this information in modules where it belongs. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
> Given that this is all about establishing some common ground between > implementations I would propose not using a CPython specific term > here such as PyStructSequence :) The Python docs seem to use structseq > for sys.float_info. Also, why does it have to be a sequence in the first place? Wouldn't a plain object with named attributes be good enough? >> compiler (required): >> verbose name of the compiler, for example "GCC 4.3.3", "Java >> HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" > > What's the value of this attribute? The main reason I ask is there's > no way that I know of to determine the JIT being used in .NET. We could > of course fill in some dummy value here for IronPython but I'm also not > sure why anyone would use this. Also, why is it the name of the JIT compiler, and not the name of the source language compiler? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
> sys.implementation is a PyStructSequence that contains various > information about the current implementation. Some fields are required > to be present on every implementation. I think it is important to confirm in advance that all the implementations listed below agree to implement the PEP "soonish" after it's adopted. "Required" sounds like a strong term - however, if an implementation chooses not to implement the PEP, it can do whatever it wants, including omission of required fields. > id (required): > lower case identifier, for example "cpython", "ironpython", "jython", > "pypy" Doing some bike-shedding: I'd like to not use "cpython" as the name of the python.org implementation. This term, I believe, was coined around JPython, somehow making the implementation language the primary means of distinction. However, there may be alternative implementations written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. pypy). So I propose that the python.org version is identified as "python". > name (required): > mixed case name of the implementation, for example "CPython", > "IronPython", "Jython", "PyPy" Likewise; alternatively "python.org". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Martin v. Löwis wrote: >> Given that this is all about establishing some common ground between >> implementations I would propose not using a CPython specific term >> here such as PyStructSequence :) The Python docs seem to use structseq >> for sys.float_info. > > Also, why does it have to be a sequence in the first place? Wouldn't > a plain object with named attributes be good enough? Any object with attributes is good enough. For CPython a structseq provides the necessary feature of a read only object with attributes. I figured out it's the easiest way to archive the goal without creating a new class. > >>> compiler (required): >>> verbose name of the compiler, for example "GCC 4.3.3", "Java >>> HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" >> What's the value of this attribute? The main reason I ask is there's >> no way that I know of to determine the JIT being used in .NET. We could >> of course fill in some dummy value here for IronPython but I'm also not >> sure why anyone would use this. > > Also, why is it the name of the JIT compiler, and not the name of the > source language compiler? The term "source language compiler" describes the intent of the field perfectly. Thanks Martin! I was merely guessing what the compiler name may look like on Jython. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Martin v. Löwis wrote: So I propose that the python.org version is identified as "python". But then we won't have a generic term for the language itself, independent of any implementation. The "c" in cpython doesn't necessarily have to refer to the implementation language. Maybe it stands for "classic python". :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Martin v. Löwis wrote: >> sys.implementation is a PyStructSequence that contains various >> information about the current implementation. Some fields are required >> to be present on every implementation. > > I think it is important to confirm in advance that all the > implementations listed below agree to implement the PEP "soonish" after > it's adopted. "Required" sounds like a strong term - however, if an > implementation chooses not to implement the PEP, it can do whatever it > wants, including omission of required fields. Please let me rephrase my suggestion. If an implementation wants implemented the PEP it is required to provide a well defined set of attributes. Of course I'm open for any suggestions regarding names, specification and content of the attribues. > Doing some bike-shedding: I'd like to not use "cpython" as the name of > the python.org implementation. This term, I believe, was coined around > JPython, somehow making the implementation language the primary means > of distinction. However, there may be alternative implementations > written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. > pypy). > > So I propose that the python.org version is identified as "python". CPython is a well established term that is widely used to distinguish between multiple implementations of Python as a language. On the one hand the python.org implementation was the first one. It founded the language and made it popular. On the other hand it may look arrogant from the perspective of the other implementors if we choose to use "python" as the identifier for the python.org implementation. In my opinion we should let Guido decide about the identifier before we have another bike-shedding war. ;-) >> name (required): >> mixed case name of the implementation, for example "CPython", >> "IronPython", "Jython", "PyPy" > > Likewise; alternatively "python.org". Interesting suggestion. Guido? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Dino Viehland wrote: > Given that this is all about establishing some common ground between > implementations I would propose not using a CPython specific term > here such as PyStructSequence :) The Python docs seem to use structseq > for sys.float_info. You got me! :) >> compiler (required): >> verbose name of the compiler, for example "GCC 4.3.3", "Java >> HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" > > What's the value of this attribute? The main reason I ask is there's > no way that I know of to determine the JIT being used in .NET. We could > of course fill in some dummy value here for IronPython but I'm also not > sure why anyone would use this. Martin has already answered both points to my satisfaction. Do you agree with him? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Christian wrote: > > Martin has already answered both points to my satisfaction. Do you > agree with him? Sure, source level makes more sense - so we'd have "csc" or "gmcs" if compiled with Mono (assuming there's some way to do that...). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
Benjamin Peterson wrote: > I think we should make a semi-private (public to the stdlib) module > like _sys or _implementation part of the Python VM API. Then, instead > of stuffing everything into sys, we can provide this information in > modules where it belongs. That's an interesting counter proposal. Your idea requires an additional import that I try to avoid. Looking at memory and performance, an additional module that is imported anyway isn't better. In my humble opinion the implementation information belongs into the sys module anyway. A new module just for the user site suffix seems unnecessary. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
2009/10/9 Christian Heimes : > Benjamin Peterson wrote: >> I think we should make a semi-private (public to the stdlib) module >> like _sys or _implementation part of the Python VM API. Then, instead >> of stuffing everything into sys, we can provide this information in >> modules where it belongs. > > > That's an interesting counter proposal. Your idea requires an additional > import that I try to avoid. Looking at memory and performance, an > additional module that is imported anyway isn't better. In my humble > opinion the implementation information belongs into the sys module > anyway. A new module just for the user site suffix seems unnecessary. But we want to hide that this is an implementation detail from the user. Having a new module just for this attribute might seem like overkill, but I hope that we could use it for more things in the future. Besides, if _sys is a builtin module, importing it will not add much overhead. I forgot to ask before: Does this deprecate platform.python_implementation()? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
On Fri, Oct 9, 2009 at 18:14, Benjamin Peterson wrote: > 2009/10/9 Christian Heimes : > > Benjamin Peterson wrote: > >> I think we should make a semi-private (public to the stdlib) module > >> like _sys or _implementation part of the Python VM API. Then, instead > >> of stuffing everything into sys, we can provide this information in > >> modules where it belongs. > > > > > > That's an interesting counter proposal. Your idea requires an additional > > import that I try to avoid. Looking at memory and performance, an > > additional module that is imported anyway isn't better. In my humble > > opinion the implementation information belongs into the sys module > > anyway. A new module just for the user site suffix seems unnecessary. > > But we want to hide that this is an implementation detail from the > user. Having a new module just for this attribute might seem like > overkill, but I hope that we could use it for more things in the > future. To also address Christian's import worry, this new module could contain everything needed to start the interpreter, much like _warnings does compared to warnings. But I honestly don't see why this doesn't belong in sys; it has to do with the system environment which is the interpreter. Yes, some things currently in sys could possibly be put elsewhere (e.g. the exception stuff could be in 'exceptions'), but I don't think sys is that much of an odd collection of code. Without having a desire to eventually clean up the sys module (which I am not proposing as I know that will never fly) I don't see this as being worth it. > Besides, if _sys is a builtin module, importing it will not > add much overhead. > Well, that's assuming the other interpreters makes it built-in. Otherwise it's only a CPython/python.org perk. > > I forgot to ask before: Does this deprecate > platform.python_implementation()? Probably should. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
2009/10/9 Brett Cannon : > But I honestly don't see why this doesn't belong in sys; it has to do with > the system environment which is the interpreter. Yes, some things currently > in sys could possibly be put elsewhere (e.g. the exception stuff could be in > 'exceptions'), but I don't think sys is that much of an odd collection of > code. Without having a desire to eventually clean up the sys module (which I > am not proposing as I know that will never fly) I don't see this as being > worth it. That doesn't mean we have to make it more dirty. usersiteprefix is used exclusively by site.py to load user modules; it has no function in the interpreter core. >> Besides, if _sys is a builtin module, importing it will not >> add much overhead. > > Well, that's assuming the other interpreters makes it built-in. Otherwise > it's only a CPython/python.org perk. As far as I am aware, all current Python implementations can build in modules. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
