Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 10:05 AM, David Bolen wrote: Kristján Valur Jónsson writes: Now, I know that this msvc behaviour can be disabled, but it was decided that it was not appropriate to meddle with runtime flags of the whole process for python. I must have missed that discussion, but I can't see what the problem is if such an override only occurs during the buildbot non-interactive test runs? Isn't that what using -n in the buildbot test.bat did? The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. I'm inclined to agree that Python itself (ie, pythonxx.dll on windows) has no business changing these flags, but it should be up to the application - ie, either python.exe itself, or exposed to the python app - the latter of which is what my patch offers. Note however that my patch doesn't cause any .py code to actually change the flags, just offers the ability for them to do so. Curt's suggestion of redirecting to a file is better still - I'll look at tweaking my patch to also offer that capability... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Mark Hammond writes: > The issue was that Python unconditionally changed the behaviour of the > CRT, not only during the test suite. Hmm... I was more or less referring to the state of the py3k tree as of, say, r57823 back in 2007. It appeared to just add access to the necessary functions in the msvcrt module, and a -n/--nowindow option to regrtest.py which then used those functions to disable stuff before running the test, and finally added -n to the tools/buildbot/test.bat file, so things got disabled in buildbot test runs. (By disabled, I believe that all of the CRT warning/error/assert went to stderr) So nothing permanently built into Python, nor enabled outside of a buildbot regression test. I agree permanently disabling them wouldn't make sense, but I thought we also agreed to that back in 2007? -- David PS: The dialogs are showing up again on my build slave. I tried clearing it but then like 6+ of them showed up and kept showing up even though I kept aborting them (I guess the tests kept running new python_d instances or something). I finally managed to catch up and then whack the python_d processes manually through task manager. Really seems like disabling them can only make things more robust, otherwise the Windows build slaves are just going to keep ending up unresponsive. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Right. In fact, having embedded python25.dll into an app once, I'm inclined to think that there is a lot of stuff that should be moved from that dll into python.exe, like argument parsing, path magic, and so on. Py_Initialize() really is designed in terms of python.exe Anyway, What I was trying to say is that there are other things that can cause dialogue boxes to pop up beside this. Assertions in other libraries, unhandled exceptions, and whatnot. Surely, all of this poses a problem on windows? Are the windows buildbots currently run as services, or are they started manually? I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Mark Hammond Sent: 25. mars 2009 08:44 To: David Bolen Cc: python-dev@python.org Subject: Re: [Python-Dev] Test failures under Windows? On 25/03/2009 10:05 AM, David Bolen wrote: > Kristján Valur Jónsson writes: > >> Now, I know that this msvc behaviour can be disabled, but it was >> decided that it was not appropriate to meddle with runtime flags of >> the whole process for python. > > I must have missed that discussion, but I can't see what the problem > is if such an override only occurs during the buildbot non-interactive > test runs? Isn't that what using -n in the buildbot test.bat did? The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. I'm inclined to agree that Python itself (ie, pythonxx.dll on windows) has no business changing these flags, but it should be up to the application - ie, either python.exe itself, or exposed to the python app - the latter of which is what my patch offers. Note however that my patch doesn't cause any .py code to actually change the flags, just offers the ability for them to do so. Curt's suggestion of redirecting to a file is better still - I'll look at tweaking my patch to also offer that capability... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 7:58 PM, David Bolen wrote: Mark Hammond writes: The issue was that Python unconditionally changed the behaviour of the CRT, not only during the test suite. Hmm... I was more or less referring to the state of the py3k tree as of, say, r57823 back in 2007. I was referring to the issue described in http://bugs.python.org/issue4804, which notes that exceptions.c unconditionally called: _CrtSetReportMode(_CRT_ASSERT, 0); which has the effect of disabling crt assertions that would otherwise result in a modal dialog. That bug remains open though, so maybe I'm confused about the problem which started this discussion... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. There is, and Curt pointed out one strategy for achieving this without losing the checks it provides... > Curt's suggestion of redirecting to a file is better still - I'll look > at tweaking my patch to also offer that capability... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
2009/3/25 Steve Holden : > As far as memory serves, Mike built the installers precisely by using > distutils to build Windows installers. He then had to suffer criticism > from people who suggested this was inappropriately complex for pure > Python modules. > > In so far as "end users" won't wish to install individual Python modules > this argument may have had some merit, but I personally thought the > criticism unjustified since Mike's technique gave a uniform install > procedure for everything. I've lost the context for this discussion completely, but can I offer a couple of points from a Windows user's point of view: 1. Using distutils to build Windows installers for pure-python packages is, in my view, *entirely* appropriate. The uniform install procedure (and more importantly, uniform *un*install procedure) is a key benefit for me. I can (and do) build my own installers for pure-python modules which do not come with an installer (easy enough, precisely because it's pure Python) but I feel that it's considerate and helpful of distributors to offer bdist_wininst (or bdist_msi) installers even when all it saves is a bit of my time. 2. Setuptools messes this clean picture up, for reasons I cannot understand, but which annoy me intensely. When setuptools is involved, it changes the default bdist_wininst behaviour somehow, so that the installers become version-specific. This increases the burden on distributors, which as a result means that you are less likely to find bdist_wininst installers for setuptools-using pure python packages (yes, I know, they give you eggs, and easy_install, yadda yadda...) So where setuptools is involved, things do start to become "inappropriately complex" - but that is a setuptools problem, NOT an issue with providing installers. 3. Setuptools, unfortunately, has divided the Python distribution community quite badly. I'd be curious to know whether the "people who suggested this was inappropriately complex" you mention above were setuptools supporters. My (unfounded) suspicion is that the argument was "having to use a separate installer is more complex than just using easy_install" - which is a highly debatable (and frequently debated!) point of view. > I don't think anyone was suggesting that py2exe would be helpful for > writing installers--simply to reduce complexity from the user's point of > view and bundle dependencies in isolation from other applications. It > seems to do that quite well. py2exe is good at creating bundled applications with no external dependencies. It doesn't make installers for these apps, just a directory containing the exe and all supporting files. That's a completely different scenario, as you say. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Paul Moore gmail.com> writes: > > 3. Setuptools, unfortunately, has divided the Python distribution > community quite badly. Wait a little bit, and it's gonna be even worse, now that buildout and pip seem to become popular. For example, the TurboGears people are considering switching from setuptools to pip... Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but I'm not sure it'll be enough to stop people from converting to whatever of the many build/packaging systems which have been popping up recently. Combined with the current trend that everything must be exploded into lots of interdependent but separately packaged libraries (the paste/pylons syndrome... try pulling something like TurboGears2 and see how many third-party packages it installs), I fear this is going to generate a very painful user/developer experience :-( > My (unfounded) suspicion is that the argument > was "having to use a separate installer is more complex than just > using easy_install" - which is a highly debatable (and frequently > debated!) point of view. I'm not a Windows user, but I suppose it boils down to whether people are comfortable with the command-line or not (which even many Windows /developers/ aren't). Since having GUIs for everything is part of the Windows philosophy, it's a fair expectation that Python libraries come with graphical Windows installers. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Guido van Rossum wrote: > Please don't do this. We need stable APIs. Trying to switch the entire > community to use CapWord APIs for something as commonly used as > datetime sounds like wasting a lot of cycles with no reason except the > mythical "PEP 8 conformance". As I said, it's a pity we didn't change > this at the 3.0 point, but I think going forward we should try to be > more committed to slow change. Additions of new functionality are of > course fine. But renamings (even if the old names remain available) > are just noise. Even for 3.0, the only API I can recall doing this for was the threading module, and there we had the additional motivation of being able to add multiprocessing with only a PEP 8 compliant API while still having it be close to a drop-in replacement for the corresponding threading API. Having helped with that kind of rename once (and for a relatively small API at that), I'd want a *really* compelling reason before ever going through it again - it's messy, tedious and a really good way to burn volunteer time without a great deal to show for it at the end. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
2009/3/25 Kristján Valur Jónsson : > > I'm going to poke my contacts at Microsoft and ask them if there is > a way to disable popups like this for a process that runs unattended > and/or is running as a windows service. MSVC has shipped with runtime library source since the 16-bit days, so the easier thing is just to read the source code. :) It looks like there are two possible code paths for the assertion. The first code path uses functions in dbgrpt[t].c and its behavior is controlled by CrtSetReportMode and CrtSetReportFile. The second uses functions in assert.c and its behavior is controlled by _set_error_mode. Both code paths use __crtMessageBox in crtmbox.c to actually display the message box. This function -- when running as a service -- will helpfully set MB_SERVICE_NOTIFICATION before calling the USER32 MessageBox, which ensures that you'll see exactly why your service has hung the next time you actually log in with sufficient rights. :/ The variation that goes through assert.c should write to stderr for a console-mode application, so it's reasonable to assume that we're hitting the other code path -- and that Mark's suggestion to use CrtSetReportMode would address the issue. -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Greg Ewing wrote: > Would you be happier if some syntactic way to do that > were provided? > > It could perhaps be done by enhancing the part of the > 'for' loop that gets executed upon normal termination > of the iterator. > > for x in my_iter: > do_something_with(x) > else v: > handle_return_value(v) I think something like that would actually make the PEP much stronger on this front - it would promote the idea of a "final value" for iterators as a more fundamental concept that can be worked with in a non-generator context. I'm also reminded of an idea that I believe existed in the early drafts of PEP 342: using "continue value" to invoke an iterator's send() method instead of next() as part of a normal for loop. With those two ideas combined, the PEP's "yield from" expansion could then look like: for x in EXPR: _v = yield x if _v is not None: continue _v else _r: RESULT = _r (If "continue None" was defined as invoking .next() instead of .send(None), then that loop body could be simplified to just "continue yield x". However, I think it is preferable to keep the bare 'continue' and dropping off the end of the loop as invoking next(), while "continue arg" invokes send(None), since the latter form clearly *expects* the iterator to have a send() method and it is best to emit the AttributeError immediately if the method isn't there) Strangely enough, I think proposing a more general change to the iteration model to include sending values into iterators and having an accessible "final value" may actually be easier to sell than trying to sell "yield from" as a pure generator construct with no more general statement level equivalent. Trying to sell the multi-stage function iteration model and the concise expression form for invoking them from another generator all at once is a lot to take in one gulp. I suspect that angle of attack would also make *testing* this kind of code far simpler as well. For example: for value, send_arg, expected in zip(gf_under_test(), send_args, expected_values): assertEqual(value, expected) continue send_arg else result: assertEqual(result, expected_result) I'm not actually sure how you would go about writing a test driver for that example multi-stage function *without* either making some kind of change to for loops or developing some rather ugly test code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 7:25 AM, Antoine Pitrou wrote: > Paul Moore gmail.com> writes: >> >> 3. Setuptools, unfortunately, has divided the Python distribution >> community quite badly. > > Wait a little bit, and it's gonna be even worse, now that buildout and pip > seem > to become popular. For example, the TurboGears people are considering > switching > from setuptools to pip... > Yes ... this is certainly true ... > Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but > I'm not sure it'll be enough to stop people from converting to whatever of the > many build/packaging systems which have been popping up recently. Sometimes it also happens that, once one such build/packaging systems is adopted, it is difficult to switch to using another one, since apps (... and plugins systems ...) are frequently hard-coupled to the pkg sys «exotic features» and support (... what comes to my mind right now is Trac plugins which are a little bit dependant on setuptools entry points and so on ...). > >> My (unfounded) suspicion is that the argument >> was "having to use a separate installer is more complex than just >> using easy_install" - which is a highly debatable (and frequently >> debated!) point of view. > > I'm not a Windows user, but I suppose it boils down to whether people are > comfortable with the command-line or not (which even many Windows /developers/ > aren't). Perhaps there is a little bit more contextual info that I miss ... however I wanted to say something about this ... I'm not a Windows user either (... although I do use Windows hosts pretty often for testing or development purposes ;). In my case I use Ubuntu Hardy and «Debian-children-or-brothers» ... At least I see a point in using easy_install since ... - it is quite easy to install the latest pkgs directly from PyPI ... - Fresh dependencies are also retrieved from there ... ... but I dont actually use it (... I do use setuptools since apps are tightly coupled with it ;), what I do is to use distutils exts to build deb pkgs. Those are the ones that get actually installed in my PC ... I prefer this way since: - I avoid the kind of chaos created by easy_install due to the fact that I cant control and manage my file/pkg associations and inter-pkg dependencies ... so there are some kind of «dangling» references to files ... and I dont like that ... I like philosophies like the one behind dpkg + apt ... - I can safely remove the packages formerly installed, including dependencies and so on ... ... however this means that ... - Quite often distros only include stable pkgs and sometimes official debs are not up to date, ... I dont like that ... - Packaging involves an extra effort ... I definitely would like to see the day when : - easy_install allow me to control in detail my installs, pks, deps & uninsts ... and `--record` is not enought for that ... IMO - distutils extensions for debs be distributed with core (similar to rpms | msi ...), however it is possible that some dependency issues be around ... I know this is a potentially long debate possibly for distutils SIG ;) - debs can be uploaded to & distributed in PyPI ... this way it could be even possible to make easy_install use these debs and try to install them using the underlying Debian support libs ... in case they be installed ... and this is nothing but some kind of crazy «random idea» ... ... and since that day on I think I'll be seriously considering easy_install as a candidate for my installs, even if there are some other side-effects while using setuptools ... ;) > Since having GUIs for everything is part of the Windows philosophy, > it's a fair expectation that Python libraries come with graphical Windows > installers. > Possibly yes ... in my case, I dont pretty like GUI installers (but I understand that other people might like them ...) and still I build them for Py pkgs in Win32 systems, since doing so I can control what's happenning with them (not as well as with apt + dpkg ... but at least I can cleanly remove them ;), however I need to handle dependencies by hand ... :$ Well ... all this is IMO ... and I am not a proficient easy_install user either, so CMIIW ... ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote: > Paul Moore gmail.com> writes: >> >> 3. Setuptools, unfortunately, has divided the Python distribution >> community quite badly. > > Wait a little bit, and it's gonna be even worse, now that buildout and pip > seem > to become popular. For example, the TurboGears people are considering > switching > from setuptools to pip... > > Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but > I'm not sure it'll be enough to stop people from converting to whatever of the > many build/packaging systems which have been popping up recently. Combined > with > the current trend that everything must be exploded into lots of interdependent > but separately packaged libraries (the paste/pylons syndrome... try pulling > something like TurboGears2 and see how many third-party packages it > installs), I > fear this is going to generate a very painful user/developer experience :-( > I think we are in a point in Python development where we need to clearly define how dependencies work. And this has to be defined in Python (in Distutils) for the sake of standardization. I think the Language Summit tomorrow is a good place to discuss about these problems, and to make sure pip, setuptools and zc.buildout rely on the same standards and pieces. PEP 376 is my first attempt to make it happen, and my goal is to see another pre-PEP coming out of thea language summit, adressing the dependencies problem. I can't hear that setuptools has divided the Python community. It has provided solutions to real problems we had in web development. It's unperfect, and it has to be fixed and integrated into Python. But it should not be done outside Python imho. If you had worked with Zope 5 years ago, you would understand what setuptools and zc.buildout brought to these communities. And today's experience is a whole less painful trust me. But I agree that the sizes of the packages are too small now, and it has gone to far. Installing a web app like Plone is scary (+100 packages) But this is the responsability of Zope, TG, etc to distribute their packages in bigger pieces I guess. (I can't wait to be at the summit ! :)) Cheers Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Nick Coghlan wrote: > With those two ideas combined, the PEP's "yield from" expansion could > then look like: > > for x in EXPR: > _v = yield x > if _v is not None: > continue _v > else _r: > RESULT = _r Oops, got a little carried away there. Obviously, that doesn't handle thrown in exceptions the way "yield from" is intended to. So even with an adjusted for loop the full semantic expansion of 'yield from' would still need to be defined directly in terms of try/except and method calls on the underlying iterator to get the desired exception handling characteristics. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Tarek Ziadé gmail.com> writes: > > But I agree that the sizes of the packages are too small now, and it has gone > to far. Installing a web app like Plone is scary (+100 packages) I am working on a TurboGears2-based app and I just did a count of the .egg packages in the virtualenv. There are 45 of them People should really stop splitting their work into micro-libraries (with such ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of separately-packaged plugins (the repoze stuff). The Twisted approach is much saner, where you have a cohesive whole in a single package. (*) The package descriptions are worth their salt too: http://pypi.python.org/pypi/AddOns http://pypi.python.org/pypi/Extremes Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Stephen J. Turnbull wrote: > "Batteries included" > is the status quo for the (C) Python project, and I personally don't > see a strong reason to change that policy until those who favor a > package-manager-based solution have a package manager that satisfies > them! Beautifully put :) And a package based solution that satisfies everyone (or even a significant majority), be they on Windows, OS X, .deb based Linux, .rpm based Linux, some other Linux or *nix, be they a mere user or the machine admin... I think that's a problem that still has a lot of development work in front of it ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 2:45 PM, Antoine Pitrou wrote: > Tarek Ziadé gmail.com> writes: >> >> But I agree that the sizes of the packages are too small now, and it has gone >> to far. Installing a web app like Plone is scary (+100 packages) > > I am working on a TurboGears2-based app and I just did a count of the .egg > packages in the virtualenv. There are 45 of them > > People should really stop splitting their work into micro-libraries (with such > ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of > separately-packaged plugins (the repoze stuff). The Twisted approach is much > saner, where you have a cohesive whole in a single package. Yes but this means that you have to wait for the next version of the "big" package when a bug is corrected or a feature added, or you need to patch it. (or maybe use the namespace trick to override it) Having them as separated package allow different release cycles, which makes it more "agile". I think there should be a right middle between a big package and a myriad of small ones. In Zope for instance, we could probably reunite a lot of package in a single package, because they don't evolve much anymore. (things like zope.interface) Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
2009/3/25 Tarek Ziadé : > I can't hear that setuptools has divided the Python community. It has provided > solutions to real problems we had in web development. It's unperfect, > and it has to be > fixed and integrated into Python. But it should not be done outside Python > imho. It's quite possible that setuptools has solved real issues in the web development area. But it did so at the expense of ease of use for people *not* in that area. I use Python for systems admin scripts, Windows services, and database management. In my experience (and I agree, it's only one, limited, use case) availability of download-and-run bdist_wininst installers for every package I used was the only significant requirement I had for Python package distribution (I remember pre-distutils days, when being able to install a 3rd party package on Windows was a nightmare of build-it-yourself guesswork). Since setuptools came on the scene, I can state with some certainty that many packages which would otherwise have been distributed as bdist_wininst installers, now aren't. In some cases, only source packages are provided (on the basis that easy_install will build what you need). In those cases, I can accept that maybe the developer would not have built Windows installers even before setuptools arrived. But in a significant number of cases - including setuptools itself - binary, version-specific eggs for Windows are provided, but no bdist_wininst installers. If the developer is willing to build an egg, he could just as easily have built an installer - but he now has to choose - build one or the other, or both. And not everyone chooses the same way. Hence my comment about "dividing the community". From my limited perspective, it's about no longer having a standard Windows binary distribution format used by all, not about some sort of ideological battles. Sorry for being unclear. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Daniel (ajax) Diniz wrote: > I feel we should make the tracker more useful for core developers, > volunteers and end-users. I also think having a clear workflow helps a > lot. Yet, I'd rather have a tracker that allowed users with different > interpretations to work as they feel most comfortable than one that > requires a change of assumptions. One other thing to keep in mind (and something I try to do myself) is to include a comment saying *why* a particular status change was made. Yes, that doesn't help all that much when people are searching for issues at various stages, but it definitely helps: a) anyone on the nosy list (since the comment and the field changes will typically either arrive in the same email or at least close together in time) b) anyone reading the issue later (as they will see more than just a series of status changes at the bottom of the issue page) If it's a matter of the triage folks wanting to be able to mark particular kinds of issues to make them easier to find or avoid later, then keywords may be a better option than messing with the stages. Heck, you could even go for the internet UI du jour and allow free form tags rather than being restricted to just the preset list of keywords - the free form tags would be a little more experimental, with the more useful ones eventually making their way to the list of properly defined keywords. The less useful ones could fall into natural disuse without cluttering up the main keyword selection UI. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote: > > Hence my comment about "dividing the community". From my limited > perspective, it's about no longer having a standard Windows binary > distribution format used by all, not about some sort of ideological > battles. Sorry for being unclear. Are you coming to the Summit tomorrow ? If not, I'll bring up this point. I whish we will be able in the near future to build a team of people from various area of expertise, to work on these problems. Tarek > > Paul. > -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 06:03 PM 3/25/2009 +1200, Greg Ewing wrote:
I wanted a way of writing suspendable functions that
can call each other easily. (You may remember I
originally wanted to call it "call".) Then I noticed
that it would also happen to provide the functionality
of earlier "yield from" suggestions, so I adopted that
name.
I still don't see what you gain from making this syntax, vs. putting
something like this in the stdlib (rough sketch):
class Task(object):
def __init__(self, geniter):
self.stack = [geniter]
def __iter__(self):
return self
def send(self, value=None):
if not self.stack:
raise RuntimeError("Can't resume completed task")
return self._step(value)
send = next
def _step(self, value=None, exc_info=()):
while self.stack:
try:
it = self.stack[-1]
if exc_info:
try:
rv = it.throw(*exc_info)
finally:
exc_info = ()
elif value is not None:
rv = it.send(value)
else:
rv = it.next()
except:
value = None
exc_info = sys.exc_info()
if exc_info[0] is StopIteration:
exc_info = () # not really an error
self.pop()
else:
value, exc_info = yield_to(rv, self)
else:
if exc_info:
raise exc_info[0], exc_info[1], exc_info[2]
else:
return value
def throw(self, *exc_info):
if not self.stack:
raise RuntimeError("Can't resume completed task")
return self._step(None, exc_info)
def push(self, geniter):
self.stack.append(geniter)
return None, ()
def pop(self, value=None):
if self.stack:
it = self.stack.pop()
if hasattr(it, 'close'):
try:
it.close()
except:
return None, sys.exc_info()
return value, ()
@classmethod
def factory(cls, func):
def decorated(*args, **kw):
return cls(func(*args, **kw))
return decorated
def yield_to(rv, task):
# This could/should be a generic function, to allow yielding to
# deferreds, sockets, timers, and other custom objects
if hasattr(rv, 'next'):
return task.push(rv)
elif isinstance(rv, Return):
return task.pop(rv.value)
else:
return rv, ()
class Return(object):
def __init__(self, value=None):
self.value = value
@Task.factory
def sample_task(arg1, another_arg):
# blah blah
something = (yield subtask(...))
yield Return(result)
def subtask(...):
...
yield Return(myvalue)
The trampoline (the _step() method) handles the co-operative aspects,
and modifying the yield_to() function allows you to define how
yielded values are processed. By default, they're sent back into the
generator that yields them, but you can pass a Return() to terminate
the generator and pass the value up to the calling
generator. Yielding another generator, on the other hand, "calls"
that generator within the current task, and the same rules apply.
Is there some reason why this won't do what you want, and can't be
modified to do so? If so, that should be part of the PEP, as IMO it
otherwise lacks motivation for a language feature vs. say, a stdlib
module. If 'yield_to' is a generic function or at least supports
registration of some kind, a feature like this would be interoperable
with a wide variety of frameworks -- you could register deferreds and
delayed calls and IO objects from Twisted, for example. So it's not
like the feature would be creating an entire new framework of its
own. Rather, it'd be a front-end to whatever framework (or no
framework) you're using.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 12:25 PM 3/25/2009 +, Antoine Pitrou wrote: Paul Moore gmail.com> writes: > > 3. Setuptools, unfortunately, has divided the Python distribution > community quite badly. Wait a little bit, and it's gonna be even worse, now that buildout and pip seem to become popular. For example, the TurboGears people are considering switching from setuptools to pip... You mean from *easy_install* to pip. pip still uses and supports setuptools. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
2009/3/25 Tarek Ziadé : >> People should really stop splitting their work into micro-libraries (with >> such >> ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of >> separately-packaged plugins (the repoze stuff). The Twisted approach is much >> saner, where you have a cohesive whole in a single package. > > Yes but this means that you have to wait for the next version of the > "big" package > when a bug is corrected or a feature added, or you need to patch it. > (or maybe use the namespace trick to override it) > > Having them as separated package allow different release cycles, which makes > it > more "agile". Another division :-) (Not one I'll try to blame on setuptools, though :-)) Some people find larger, stable, unified packages more useful. Others find fine-grained, rapidly developing packages more useful. It sounds like Antoine and I fall into the former camp. At the risk of generalising, maybe the latter philosophy fits the "web developer" mental model better? I doubt this is related to the current discussion, though - except in that setuptools, with its claim to make managing large numbers of dependencies relatively painless, encourages people to forget the cost involved in micro-packages. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote: Sometimes it also happens that, once one such build/packaging systems is adopted, it is difficult to switch to using another one, since apps (... and plugins systems ...) are frequently hard-coupled to the pkg sys «exotic features» and support (... what comes to my mind right now is Trac plugins which are a little bit dependant on setuptools entry points and so on ...). Please note that entry points are not coupled to easy_install. They have a documented file format and API that's *distributed* with setuptools, but is not dependent on it and does not require .egg files, either. There's nothing stopping an independent implementation in the stdlib, ala PEP 376's metadata API, which is designed to be backward compatible with setuptools. It could be extended to support entry points as well. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
2009/3/25 Tarek Ziadé : > On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote: >> >> Hence my comment about "dividing the community". From my limited >> perspective, it's about no longer having a standard Windows binary >> distribution format used by all, not about some sort of ideological >> battles. Sorry for being unclear. > > Are you coming to the Summit tomorrow ? If not, I'll bring up this point. Sorry, no. I'm on the wrong continent :-) If you would, I'd appreciate it. Sometimes I feel that the distutils/setuptools discussions need better input from the non-web-developer community. And even more so from the "not a developer, just a user" community! But the various communities involved seem to struggle to appreciate each others' viewpoints, to such a great extent that it's hard to make any progress. Good luck with the Summit! Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 7:31 AM, P.J. Eby wrote: > Please note that entry points are not coupled to easy_install. They have a > documented file format and API that's *distributed* with setuptools, but is > not dependent on it and does not require .egg files, either. There's > nothing stopping an independent implementation in the stdlib, ala PEP 376's > metadata API, which is designed to be backward compatible with setuptools. > It could be extended to support entry points as well. Well, sorry, but this complex layered interdependent architecture is one of the *causes* of confusion -- apart from you nobody knows what is what exactly, and the names are often used "incorrectly". BTW this also makes it hard to find downloadable versions of these tools if you don't already know the magic Google query (and I happen to get that wrong each time I want to learn about these). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
>> Paul Moore gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse, now that buildout and pip
>> seem
>> to become popular. For example, the TurboGears people are considering
>> switching
>> from setuptools to pip...
>>
>> Combined with
>> the current trend that everything must be exploded into lots of
>> interdependent
>> but separately packaged libraries (the paste/pylons syndrome... try pulling
>> something like TurboGears2 and see how many third-party packages it
>> installs), I
>> fear this is going to generate a very painful user/developer experience :-(
>>
>
> I think we are in a point in Python development where we need to clearly
> define
> how dependencies work.
+1
> And this has to be defined in Python (in Distutils)
> for the sake of standardization.
>
Well, I mentionned I did it using apt + insinstall support ... but I'd
love to have all these things in Python ... with or without relying on
OS-specific infrastructure for managing pkgs, deps and so on ... It is
possible to have two approaches :
- a thin layer on top of OS-specific (dpkg + apt, rpm + yum,
wininstall, mac os ... ) pkg managers so that distutils be able to use
them directly whille still keeping a single model from the end-user
perspective ... At least there exists some kind of python-debian pkg
...
{{{
$ apt-cache show python-debian
Package: python-debian
Priority: optional
Section: universe/devel
Installed-Size: 268
Maintainer: Ubuntu MOTU Developers
Original-Maintainer: Debian python-debian Maintainers
Architecture: all
Version: 0.1.9
[...]
Depends: python (>= 2.4), python-support (>= 0.7.1)
Recommends: python-apt
[...]
Size: 43662
[...]
Description: python modules to work with Debian-related data formats
This package provides python modules that abstract many formats of Debian
related files. Currently handled are:
* Debtags information (debian_bundle.debtags module)
* debian/changelog (debian_bundle.changelog module)
* Packages files, pdiffs (debian_bundle.debian_support module)
* Control files of single or multple RFC822-style paragraphs, e.g
debian/control, .changes, .dsc, Packages, Sources, Release, etc.
(debian_bundle.deb822 module)
* Raw .deb and .ar files, with (read-only) access to contained
files and meta-information
[...]
}}}
Since there are a lot such systems (at least for Linux ...) ... this
could also mean that it could be very complex to handle all this
diversity ... However there are a few which are highly influential ...
but this is certainly a concern ...
- A fully fledged implementation from scratch so that distutils be in
charge, all apps be consistent with Py-std ... and users have
potentially two pkg systems (.. the built-in and the Py-specific ;) ;
and I say potentially since it's quite sudden so far and perhaps there
is a way to smoothly integrate both systems (which are potentially
many of them ;)
> I think the Language Summit tomorrow is a good place to discuss about
> these problems,
Hope it be available (recorded ?) some day so as to hear some opinions ... ;)
> and to make sure pip, setuptools and zc.buildout rely on the same
> standards and pieces.
>
Oh yes !
+1
> PEP 376 is my first attempt to make it happen, and my goal is to see another
> pre-PEP coming out of thea language summit, adressing the dependencies
> problem.
>
;)
> I can't hear that setuptools has divided the Python community.
Said like this ... some might think that setuptools is responsible for
someone else's choices and actions ... and I dont think so ...
> It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python
> imho.
>
I mostly agree with all this, but I would like to know something ...
in case a single pkg management sys be ready for Py (... I mean
integrated into Py ...) and so on ... Why will we need distutils
comands like :
bdist_msi
bdist_wininst
bdist_rpm
<... more «non-standard» candidates like py2exe, stdeb, ...>
? Will all this still be necessary and maintained ? As long as
installing /uninstalling them be handled correctly in built-in as well
as Py systems (considering the duplicate «package repositories» ...)
... I think this could be fine ... but details are details ... ;)
> If you had worked with Zope 5 years ago, you would understand what
> setuptools and
> zc.buildout brought to these communities. And today's experience is a
> whole less painful trust me.
>
Yes ... setuptools has undoubtedly its own value ... :o)
> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
>
> But this is the responsability of Zope, TG, etc to distr
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 9:01 AM, Nick Coghlan wrote: And a package based solution that satisfies everyone (or even a significant majority), be they on Windows, OS X, .deb based Linux, .rpm based Linux, some other Linux or *nix, be they a mere user or the machine admin... I think that's a problem that still has a lot of development work in front of it ;) I don't think that will ever happen. I regularly use three *nix systems and each has a different package management systems and I don't think I even want a unified package manager. Tools like setuptools, zc.buildout, etc. seem great for developers but not very good for distributions. At last year's Pycon I think there was agreement from the Linux distributors that distutils, etc. just wasn't very useful for them. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScpFE3EjvBPtnXfVAQJ6FwP9GdT9gVyfDp1aCLlfXsw61hcwU+6E3sX2 kvuqRYyXeTlecvRWnhc0YKzLjIke+4K+z7DlKxKazWaOsgkLTxxKrB1HTOwqKsiA +PxIrHK5tSKbvoBLphFQVgtDcqzb07xxxsz0KsTxWR/mskvR0eYf1/XZl3+b+9sQ M1POnOxXCN0= =8VhZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Paul Moore gmail.com> writes: > > Another division (Not one I'll try to blame on setuptools, though ) > > Some people find larger, stable, unified packages more useful. Others > find fine-grained, rapidly developing packages more useful. > > It sounds like Antoine and I fall into the former camp. At the risk of > generalising, maybe the latter philosophy fits the "web developer" > mental model better? I don't think it's a question of mental model. Whatever your mentality, having O(N) libraries means you have O(N**2) potential interdependencies to worry about (especially when those libraries are socially and functionally part of a larger ensemble). When N is 30 or 100, it's easy to see where it leads: loss of control, unmanageability, irresponsibility. The argument that you can individually upgrade each micro-library is a double-edged sword: individual upgrades can break the interaction with other micro-libraries because of subtle changes in API or behaviour. If you post on the framework's mailing-list to get help with the problem, the framework authors are unable to tell you how to solve it because /even they/ can't master the O(N**2) interdependencies. Then you must upgrade the other micro-libraries as well, which is no better than having a large cohesive package where everything evolves in lockstep by construction. (by the way, I don't think it's setuptools' fault... that's why I've used quotes in the title. People have simply abused a tool, the same way "DLL hell" is an abuse of the shared library system) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 9:02 AM, Tarek Ziadé wrote: Yes but this means that you have to wait for the next version of the "big" package when a bug is corrected or a feature added, or you need to patch it. (or maybe use the namespace trick to override it) Having them as separated package allow different release cycles, which makes it more "agile". I think there should be a right middle between a big package and a myriad of small ones. In Zope for instance, we could probably reunite a lot of package in a single package, because they don't evolve much anymore. (things like zope.interface) Maybe there's a difference between being a Zope user and using zope packages? I think it's great that I can pick and choose zope.interfaces and other packages in my not-Zope project. But if I'm deploying actual Zope-the-web-thing I just want to install it from my distro and be done with it. It's up to my distro to determine compatibility, handle bug and security fixing, etc. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScpFj3EjvBPtnXfVAQJakwP/djOrhpyZZrrqCFNG7rAi3qpZIaVLXiwk U/td3R6OyugcDrnf26+xpaWGjr5HiJsftusRdVPbZmR9kFNmOc15lmJ1b3QElpv5 dofRiQ8hMXqe+sgCm9QmRj5RyszNlALdbYKkjCMODrcKqzC1N6fPjNi03FloWKmd N89NYb75CUo= =dmRY -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 07:40 AM 3/25/2009 -0700, Guido van Rossum wrote: Well, sorry, but this complex layered interdependent architecture is one of the *causes* of confusion -- apart from you nobody knows what is what exactly, I'll pick a minor nit here... buildout, pip, and a wide variety of other tools and frameworks out there wouldn't exist if I were really the only person who knew "what's what". And I believe most of those people will be at the summit. That having been said, the setuptools documentation definitely sucks for the casual reader or curious observer, as opposed to those who have serious itches to scratch in the area of dependencies or plugins. Combine that with the practical-but-impure choices I made in easy_install to get *something* working, and you have a recipe for the current situation. pkg_resources, for example, is only bundled with setuptools because it couldn't go in the stdlib when it was written. easy_install, OTOH, is bundled with setuptools because *setuptools* isn't in the stdlib! (And of course, both use pkg_resources.) So ironically, setuptools is bundled in the way that it is, precisely *because* there's no support for dependencies in the stdlib... and nicely illustrates why smaller libraries (and less bundling) is a *good* thing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 9:31 AM, P.J. Eby wrote: > At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote: >> >> Sometimes it also happens that, once one such build/packaging systems >> is adopted, it is difficult to switch to using another one, since apps >> (... and plugins systems ...) are frequently hard-coupled to the pkg >> sys «exotic features» and support (... what comes to my mind right now >> is Trac plugins which are a little bit dependant on setuptools entry >> points and so on ...). > > Please note that entry points are not coupled to easy_install. Yes u'r right and I know ... perhaps there are better examples to illustrate what I was saying ... which is that ... distutils architecture is great since I can code «my own» extension (e.g. setuptools ;) with «my» potentially non-standard | conflicting features ... (e.g. entry points ... AFAIK they'r only de-facto standards, not in approved final PEPs ;) Note: ... I'm not saying that I've contributed to setuptools (the «my» thing ...), it's just a way of talking ... hope you dont mind ... ;) > They have a > documented file format and API that's *distributed* with setuptools, but is > not dependent on it and does not require .egg files, either. ... but Trac plugins *do require* egg files ... (AFAIK after reading Trac docs and implementation of plugin upload from /admin/plugins, egg cache for plugins ... and so on ...) and this is what I was talking about ... apps (e.g. Trac) depending *today* on setuptools (e.g. egg files ...) ... not easy_install since, in fact I could install plugins with apt (... or similar ;) too ... although I always build egg files, but this is my own decision BTW since I prefer to inherit configs & plugins for all envs ... but this is a little bit OT here since its specific to Trac ... ;) > There's > nothing stopping an independent implementation in the stdlib, ala PEP 376's > metadata API, which is designed to be backward compatible with setuptools. Of course there is nothing «stopping an independent implementation in the stdlib [...] designed to be backward compatible with setuptools.», but it is still not there ... AFAIK ... and that's what I was talking about ... considering my example ... I'd like it in there ... 2 ;) Like I said I like the idea behind easy_install, but not the «holes» I mentioned ... but I wanna see filled out ... maybe its just a matter of time ... :) > It could be extended to support entry points as well. > ... and then Trac plugins (falling-back to my example ;) will rely on std features ... in a near future ... ok ... -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 5:25 AM, Antoine Pitrou wrote: > > I'm not a Windows user, but I suppose it boils down to whether people are > comfortable with the command-line or not (which even many Windows /developers/ > aren't). Since having GUIs for everything is part of the Windows philosophy, > it's a fair expectation that Python libraries come with graphical Windows > installers. MSIs aren't only about the GUI; they're also about management. For instance, an MSI can be pushed out to clients using Active Directory. This simplifies not only initial deployment but also subsequent updates -- particularly when you're dealing with many clients. -- Curt Hagenlocher c...@hagenlocher.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: > Tarek Ziadé gmail.com> writes: >> But I agree that the sizes of the packages are too small now, and it has gone >> to far. Installing a web app like Plone is scary (+100 packages) > > I am working on a TurboGears2-based app and I just did a count of the .egg > packages in the virtualenv. There are 45 of them > > People should really stop splitting their work into micro-libraries (with such > ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of > separately-packaged plugins (the repoze stuff). The Twisted approach is much > saner, where you have a cohesive whole in a single package. Monoliths have downsides: consider that fact that the WSGI-complieant HTTP server for Twisted languished for *years* outside the released versions of Twisted: IIRC, the server was released as a separate distribution, but it was not compatible with the released versions of the main Twisted distribution: you had to install a snapshot / alpha of Twisted to get the 'web2' server to work. Repoze ships a number of pieces which may not be interesting to all users: - repoze.bfg is a web-application framework, loosely Zope-like, which reuses a fairly small subset of the Zope libraries. - repoze.who is an web authentication framework, which can be used in conjunction with *any* web application which respsects at least the REMOTE_USER key in the WSGI environment. TurboGears is now using this piece, even though they don't use any other repoze.* packages. - The various "middleware" packages are tiny, conherent, and can be used ad libidem in a WSGI pipeline. WSGI itself, like Unix pipes, favors composition of smaller pieces via a simple API: a given deployment can add stuff like profiling, etc. just be adding a new "layer" in the pipeline. Putting the profiler into a larger package would make it less likely to be used across frameworks. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJyk8T+gerLs4ltQ4RAiVkAKCJbtyDpYYww30P2SupovVTNx39jgCgtPBF XUEJbfXz5LHqBgpHs+hXrqk= =cNYq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Someone asked for the input of "ordinary users" (i.e. non developers) which, unfortunately, most of the people on this list don't fall in. My experience with setuptools is that it's poorly documented and assumes a level of sophistication that isn't always there. While this is fine in a lot of arenas, installation of things shouldn't be an area where I have to guess between multiple interpretations of documentation AND have a thorough knowledge of some of the nuts and bolts of interdependencies. Maybe having an "easily extensible" language is not consistent with having an "easy to extend" language, but the current arrangement seems untenable. -- Haikus are easy Most make very little sense Refrigerator ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: > Maybe there's a difference between being a Zope user and using zope > packages? I think it's great that I can pick and choose > zope.interfaces and other packages in my not-Zope project. But if I'm > deploying actual Zope-the-web-thing I just want to install it from my > distro and be done with it. It's up to my distro to determine > compatibility, handle bug and security fixing, etc. Historically, the distros have done a less than stellar job here, too. They change the deployment model to such an extent that the core Zope developers can't support the users of the distro-packaged Zopes (this is a common complaint among *lot* of upstream projects, not just Zope: try getting support for a distro-packaged kernel on lkml, for instance). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJyk/X+gerLs4ltQ4RAsZoAJ4ybFXYzYIclbI7YYHPj0PrlzvxPACZAaEC B9Wl+B3LKwjldzZ6D2LEyHM= =PBji -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Barry Warsaw wrote: > Tools like setuptools, zc.buildout, etc. seem great for developers but > not very good for distributions. At last year's Pycon I think there was > agreement from the Linux distributors that distutils, etc. just wasn't > very useful for them. > It's decent for modules but has limitations that we run up against somewhat frequently. It's a horror for applications. -Toshio signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote: ... but Trac plugins *do require* egg files ... (AFAIK after reading Trac docs and implementation of plugin upload from /admin/plugins, egg cache for plugins ... and so on ...) and this is what I was talking about ... apps (e.g. Trac) depending *today* on setuptools (e.g. egg files ...) Trac uses entry points to access plugins. Those plugins do not require .egg files, unless Trac specifically wrote code of their own that requires .egg files. If you install a plugin from source using pip or a system package manager, no .egg file is involved -- you'll have an .egg-info directory instead, alongside the installed code. The pkg_resources API for accessing entry points works with either .egg files or .egg-info directories. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 12:37 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Barry Warsaw wrote: > >> Maybe there's a difference between being a Zope user and using zope >> packages? I think it's great that I can pick and choose >> zope.interfaces and other packages in my not-Zope project. But if I'm >> deploying actual Zope-the-web-thing I just want to install it from my >> distro and be done with it. It's up to my distro to determine >> compatibility, handle bug and security fixing, etc. > > Historically, the distros have done a less than stellar job here, too. I don't think that's entirely accurate. For softwares which I don't care directly as a developer, because I only use them, and don't intend to change anything in it, the linux distribution is god's heaven IMO. Being able to update, upgrade everything in a centralized, predictable manner works very well. It fails for software I am directly involved in, or maybe the layer just below: for example, there is no way for me to get a python 2.6 on my distribution (Ubuntu), so I cannot easily test the python projects I am involved in for python 2.6. But for layers below, it is almost perfect. If python, as a platform, could be as reliable as debian, I would be extremely happy. I just don't think it is possible, because of the huge amount of work this requires. Tools are just a small part of it - you need a lot of discipline and work to make sure everything fits together, and that can't happen for every python lib/application out there. I already mention this on the distutils ML, but IMO, the only workable solution is to have a system which makes it *possible* for OS distributors to package in whatever they see fit (.deb, .rpm, .dmg, .exe, .msi). Distutils, as of today, makes it much harder than it is for non trivial softwares (documentation, controlling what goes where, etc...). That's something we can hope to improve. Again, I will take the autoconf example: it has no policy, and can be used for different kind of situations, because you can (if you want) control things in a very fine-grained manner. Automatic, 'native' installers which are well integrated into every system, this seems so far from reach I don't see how this can even be considered. cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 11:04 AM, P.J. Eby wrote: > At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote: >> >> ... but Trac plugins *do require* egg files ... (AFAIK after reading >> Trac docs and implementation of plugin upload from /admin/plugins, egg >> cache for plugins ... and so on ...) and this is what I was talking >> about ... apps (e.g. Trac) depending *today* on setuptools (e.g. egg >> files ...) > > Trac uses entry points to access plugins. Those plugins do not require .egg > files, unless Trac specifically wrote code of their own that requires .egg > files. > Yes you're right, Trac requires .egg files for local plugins installs (... in /plugins folder ;) so that not all environments but only one be able to use the plugin ... but that's not exactly what I'm saying, since setuptools AFAIK *MUST* be already there ... so Trac depends on setuptools. > If you install a plugin from source using pip Like you said setuptools is already there ... pip depends on setuptools ... isn't it? > or a system package manager, > no .egg file is involved -- you'll have an .egg-info directory instead, > alongside the installed code. The pkg_resources API for accessing entry > points works with either .egg files or .egg-info directories. > Like I just said setuptools AFAIK *MUST* be there ... isnt it ? Am I still wrong ? BTW ... if you (or anyone else ;) suggests me another pkg «like» setuptools (supporting entry points and so on ...) so that I can try how to install and use Trac plugins without setuptools + pkg_* in the middle ... I'll be open to try it out ... and learn a little ;) PS: Sorry if I insist «too much» ... BTW I am not very sure about whether this getting a little bit OT or not ... hope this isnt the case ... but if it is, pls let me know ASAP ... ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, 25 Mar 2009 11:34:43 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: Tarek Ziadé gmail.com> writes: But I agree that the sizes of the packages are too small now, and it has gone to far. Installing a web app like Plone is scary (+100 packages) I am working on a TurboGears2-based app and I just did a count of the .egg packages in the virtualenv. There are 45 of them People should really stop splitting their work into micro-libraries (with such ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of separately-packaged plugins (the repoze stuff). The Twisted approach is much saner, where you have a cohesive whole in a single package. Monoliths have downsides: consider that fact that the WSGI-complieant HTTP server for Twisted languished for *years* outside the released versions of Twisted: IIRC, the server was released as a separate distribution, but it was not compatible with the released versions of the main Twisted distribution: you had to install a snapshot / alpha of Twisted to get the 'web2' server to work. Maybe monoliths have downsides, but please pick a different example to support this. The manner in which the WSGI server in Twisted Web2 was made available has very little to do with large vs small packages and much to do with our (the Twisted developers) decision /not/ to release Twisted Web2 at all. I could go into lots more detail about that decision, but I don't think any of i would be relevant to the topic at hand. If anything, Twisted's example shows how monolithic packages are easier all-around than micro-packages. We basically have the release infrastructure to release Twisted in many smaller pieces, and we even do - but we only make releases of all the smaller pieces simultaneously, we encourage people to use the "Twisted" package which includes all the pieces, and we don't do any testing of mixed versions of the smaller pieces because it would be very difficult. Further, we *have* done point releases of /all/ of Twisted to supply some critical bug fix (these generally take the form of a X.Y.1 release, we rarely go to .2 or higher these days). And we've done these quite rapidly when the need arises - the monolithic nature of Twisted isn't really a hindrance here (updating our website, a manual process, is far more time consuming than actually doing the release - and a big part of that cost comes from the fact that we have web pages for each smaller piece, even though we don't encourage people to use these!). So, as long as we're just talking about the vagueries of "monolithic" vs "micro", I'll weigh in in favr of monolithic (but I'm open to discussion about specific issues which are much more interesting than abstractions). Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures under Windows?
Curt Hagenlocher writes: > The variation that goes through assert.c should write to stderr for a > console-mode application, so it's reasonable to assume that we're > hitting the other code path -- and that Mark's suggestion to use > CrtSetReportMode would address the issue. Which is pretty much what the regrtest.py -n option does/did in the py3k branch (and release30-maint). It enables the following code: import msvcrt msvcrt.SetErrorMode(msvcrt.SEM_FAILCRITICALERRORS| msvcrt.SEM_NOALIGNMENTFAULTEXCEPT| msvcrt.SEM_NOGPFAULTERRORBOX| msvcrt.SEM_NOOPENFILEERRORBOX) try: msvcrt.CrtSetReportMode except AttributeError: # release build pass else: for m in [msvcrt.CRT_WARN, msvcrt.CRT_ERROR, msvcrt.CRT_ASSERT]: msvcrt.CrtSetReportMode(m, msvcrt.CRTDBG_MODE_FILE) msvcrt.CrtSetReportFile(m, msvcrt.CRTDBG_FILE_STDERR) which seems like it would still be the right sort of code to use. For my buildbot the SetErrorMode is redundant because I already do that in the buildbot code itself (and the setting is inherited) but it won't hurt. >From what I can see though, the tools/buildbot/test.bat file no longer adds the -n option that it used to, although I'm unclear on why it might have been removed. Perhaps this was just a regression that was accidentally missed, as it appears to have disappeared during a large merger from trunk to the py3k branch mid-2008 (r64273) when the batch file line ending was changed to CRLF. It would be nice to also have this in the other active release branches. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Paul Moore wrote: 2009/3/25 Tarek Ziadé : Since setuptools came on the scene, I can state with some certainty that many packages which would otherwise have been distributed as bdist_wininst installers, now aren't. In some cases, only source packages are provided (on the basis that easy_install will build what you need). In those cases, I can accept that maybe the developer would not have built Windows installers even before setuptools arrived. But in a significant number of cases - including setuptools itself - binary, version-specific eggs for Windows are provided, but no bdist_wininst installers. If the developer is willing to build an egg, he could just as easily have built an installer - but he now has to choose - build one or the other, or both. And not everyone chooses the same way. Is it possible to write an egg to bdist converter (or vice versa)? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Antoine Pitrou wrote: Tarek Ziadé gmail.com> writes: But I agree that the sizes of the packages are too small now, and it has gone to far. Installing a web app like Plone is scary (+100 packages) I am working on a TurboGears2-based app and I just did a count of the .egg packages in the virtualenv. There are 45 of them People should really stop splitting their work into micro-libraries (with such ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of separately-packaged plugins (the repoze stuff). The Twisted approach is much saner, where you have a cohesive whole in a single package. (*) The package descriptions are worth their salt too: http://pypi.python.org/pypi/AddOns http://pypi.python.org/pypi/Extremes Thoughts: 1. These are modules, not packages, hence should be relatively small. 2. These are general utilities and have nothing in particular to do with peak. 3. If I wanted one of these, I would be happy that they are separately indexed and downloadable. 4. If I used one of these in an app, I would include them within the app and not have them be separate pieces. 5. Much of this discussion reminds me of the debates between lumping and splitting of taxonomic categories in biology. Like that debate, it will continue forever. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Is setuptools/distutils/whatever on the agenda for the tomorrow's language summit? Or is there some other get-together at PyCon for this? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Yes it's on the agenda On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote: Is setuptools/distutils/whatever on the agenda for the tomorrow's language summit? Or is there some other get-together at PyCon for this? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote: > I use Python for systems admin scripts, Windows services, and database > management. In my experience (and I agree, it's only one, limited, use > case) availability of download-and-run bdist_wininst installers for > every package I used was the only significant requirement I had for > Python package distribution (I remember pre-distutils days, when being > able to install a 3rd party package on Windows was a nightmare of > build-it-yourself guesswork). > > Since setuptools came on the scene, I can state with some certainty > that many packages which would otherwise have been distributed as > bdist_wininst installers, now aren't. In some cases, only source > packages are provided (on the basis that easy_install will build what > you need). In those cases, I can accept that maybe the developer would > not have built Windows installers even before setuptools arrived. But > in a significant number of cases - including setuptools itself - > binary, version-specific eggs for Windows are provided, but no > bdist_wininst installers. If the developer is willing to build an egg, > he could just as easily have built an installer - but he now has to > choose - build one or the other, or both. And not everyone chooses the > same way. I'd just like to chime in and agree with Paul here. I'm a Windows user, and I won't install a Python module that I can't get as a wininst (or preferably a .msi), because I prefer to use the Windows package management system, not some Python specific thing. I can generally build installers myself for Python-only packages, but binary ones are harder. And I've seen several projects with exactly the kind of thing Paul describes - where a good Windows installer would probably have been available if it weren't for the interference of setuptools. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
GSOC? On Thu, Mar 26, 2009 at 6:05 AM, Steven Bethard wrote: > On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote: > > I use Python for systems admin scripts, Windows services, and database > > management. In my experience (and I agree, it's only one, limited, use > > case) availability of download-and-run bdist_wininst installers for > > every package I used was the only significant requirement I had for > > Python package distribution (I remember pre-distutils days, when being > > able to install a 3rd party package on Windows was a nightmare of > > build-it-yourself guesswork). > > > > Since setuptools came on the scene, I can state with some certainty > > that many packages which would otherwise have been distributed as > > bdist_wininst installers, now aren't. In some cases, only source > > packages are provided (on the basis that easy_install will build what > > you need). In those cases, I can accept that maybe the developer would > > not have built Windows installers even before setuptools arrived. But > > in a significant number of cases - including setuptools itself - > > binary, version-specific eggs for Windows are provided, but no > > bdist_wininst installers. If the developer is willing to build an egg, > > he could just as easily have built an installer - but he now has to > > choose - build one or the other, or both. And not everyone chooses the > > same way. > > I'd just like to chime in and agree with Paul here. I'm a Windows > user, and I won't install a Python module that I can't get as a > wininst (or preferably a .msi), because I prefer to use the Windows > package management system, not some Python specific thing. I can > generally build installers myself for Python-only packages, but binary > ones are harder. And I've seen several projects with exactly the kind > of thing Paul describes - where a good Windows installer would > probably have been available if it weren't for the interference of > setuptools. > > Steve > -- > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a > tiny blip on the distant coast of sanity. >--- Bucky Katt, Get Fuzzy > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In case I seem to disappear...
Sounds better than being hit by a bus, though! :) 2009/3/24 Guido van Rossum : > I've received several emails recently indicating that someone is > trying to get me unsubscribed from python-dev. I'm sure they're just > pranksters, but just in case they succeed, if I seem to be absent for > a really long time, let me know. After all mailman passwords are not > secure. :-) > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/benjamin%40python.org > -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More GSoC - make sure you list your projects!
Hi all, just a quick note -- anyone who has an idea for a core Python Google Summer of Code project, has not had that project panned on this list ;), and is willing to act as a CONTACT for students who want to apply (not necessarily a mentor!) should make sure that those ideas are posted on the wiki, at http://wiki.python.org/moin/SummerOfCode/2009 Without a contact and a link on the wiki page, students won't have any idea that the project exists... I will endeavor to find mentors for as many of the core Python projects as possible, once we have a clearer sense of how many applicants we have and how many applications are good. cheers, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Yes, I'll try to blog today the initial list of topics that will be discussed during the Summit, Regards Tarek 2009/3/25 Jesse Noller : > Yes it's on the agenda > > On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote: > >> Is setuptools/distutils/whatever on the agenda for the tomorrow's language >> summit? Or is there some other get-together at PyCon for this? >> >> Skip >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Paul Moore writes: > If you would, I'd appreciate it. Sometimes I feel that the > distutils/setuptools discussions need better input from the > non-web-developer community. And even more so from the "not a > developer, just a user" community! And the often-obscured community: those who desperately want the Python stuff to just behave the same way everything else on their system does, i.e. be managed approrpiately by the operating system package manager. A Python-specific packaging system which makes it harder to fit Python packages into a broader OS policy works very much at odds with that. However, I, too, am on a different continent from the conference. -- \“Kill myself? Killing myself is the last thing I'd ever do.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
2009/3/25 Terry Reedy : > Is it possible to write an egg to bdist converter (or vice versa)? No idea. But would it help? Distributors would still only provide one or the other, so when only an egg is available, I'd still have to convert it - which is certainly pretty simple, but so is python setup.py bdist_wininst. I don't think it's simply about how easy it is to create installers for yourself. If a developer provides an egg, and I convert it to a bdist_wininst, who helps me if there's an installation problem? (Assume "me" is someone just trying to use Python as a tool - say, one of the scientists David Cournapeau referred to earlier in the thread). Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 11:16 AM, David Cournapeau wrote: It fails for software I am directly involved in, or maybe the layer just below: for example, there is no way for me to get a python 2.6 on my distribution (Ubuntu), so I cannot easily test the python projects I am involved in for python 2.6. At least it's better now so that if you install it from source and throw a bunch of modules into site-packages, you won't kill your distro. :) I already mention this on the distutils ML, but IMO, the only workable solution is to have a system which makes it *possible* for OS distributors to package in whatever they see fit (.deb, .rpm, .dmg, .exe, .msi). Distutils, as of today, makes it much harder than it is for non trivial softwares (documentation, controlling what goes where, etc...). That's something we can hope to improve. Again, I will take the autoconf example: it has no policy, and can be used for different kind of situations, because you can (if you want) control things in a very fine-grained manner. Automatic, 'native' installers which are well integrated into every system, this seems so far from reach I don't see how this can even be considered. I agree. With my developer's hat on, I can't know all the crazy places my package will be used, so distutils is great because at least it's easy for me to write a setup.py, push my package to some place, and share it with other developers. My hope of course is that the setup.py is useful to distros who want to include my package in their offering. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScq4enEjvBPtnXfVAQIOpAP/bJsMn7iKyIOhm8iGxWfeNhtaesCXy2MZ eU8KyI0xvtACleLzzZd8mX79QyNw02WTfct6BX83NHuBs2Kyu6S0jjNMfz6zzSNs Se4qjQTu8Iw/JPCyxq6XOiTQaVkbtSNs93xAWjHfeX6PumkKn+qd5Lx3KuBPDE+X vcTPOlq0X20= =UsYX -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python The prime limitation of setuptools appears to me to come when there are conflicts. Other than that, for packages where it is available, I have never had an issue with the functioning of setuptools. It's Just Fine. For issues where there are conflicts, where I have been sufficiently motivated, setting up a virtualenv has more than met my needs. In fact, that's and *awesome* piece of functionality. For case one, where I want to install additional functionality into my system Python interpreter "forever", it would be great to have my system manage this. On my ubuntu machine, this happens. The Ubuntu packages take care of things very satisfactorily and I don't see how anyone would have a problem with it. I don't know what the situation is under Windows, however systems such as the Enthought Python Suite do provide kitchen-sink-included Python distributions. Perhaps an automated updates site could be configured such that there was a package for a variety of "Python + some extra modules" scenarios. For installing applications, I would presume that app developers would generally take care of this themselves, through the use of an MSI or .deb file in order to protect their dependencies somewhat. For anyone looking to extend their interpreter for some specific task, virtualenv and setuptools should do the job, and the developer can just go the extra mile to do the work to get it right themselves. Perhaps the most under-served use case is people who want a kitchen-sink-included distribution, to be managed by their system packages. Either they are not away of systems such as EPS or are opposed to it in principle. Were time and effort no obstacle, I would suggest that it may be worth Python.org offering to host and/or maintain a variety of Python distributions available for installation which include various standard extensions. The model that eclipse takes, with a "base" system and plugins, but with flavoured versions available (i.e. Scientic Python Distribution to include SciPy, Numpy and MatPlotLib for example). Thoughts? On Thu, Mar 26, 2009 at 9:56 AM, Ben Finney < bignose+hates-s...@benfinney.id.au >wrote: > Paul Moore writes: > > > If you would, I'd appreciate it. Sometimes I feel that the > > distutils/setuptools discussions need better input from the > > non-web-developer community. And even more so from the "not a > > developer, just a user" community! > > And the often-obscured community: those who desperately want the > Python stuff to just behave the same way everything else on their > system does, i.e. be managed approrpiately by the operating system > package manager. A Python-specific packaging system which makes it > harder to fit Python packages into a broader OS policy works very much > at odds with that. > > However, I, too, am on a different continent from the conference. > > -- > \“Kill myself? Killing myself is the last thing I'd ever do.” | > `\—Homer, _The Simpsons_ | > _o__) | > Ben Finney > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com > -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote: Yes you're right, Trac requires .egg files for local plugins installs (... in /plugins folder ;) so that not all environments but only one be able to use the plugin ... but that's not exactly what I'm saying, since setuptools AFAIK *MUST* be already there ... so Trac depends on setuptools. I've not looked at Trac's plugin architecture, but I wonder, how much of it is generic enough to be useful for any application? I've found setuptools entry points difficult to work with for plugins, and I think the Python ecosystem could benefit from more shared wisdom, if not code, in designing plugin frameworks for applications. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScq5b3EjvBPtnXfVAQIdDAP+OHWHqbYhpAuokfOQ4+dDp48aFNZMaDDs F5IzPZA5Hjvv0r/lkdV06FCxmx24tXxkBnPSrFHbR5iK5pwFsORwf8YWib5S5IPh DBQLAeBfM0LbzlGp1/p6Aa8xK2lAShTcNrjyWsuWYskUHp66quwQ1IzF6ROOEMjz bUy9hxiwEx8= =RVyF -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 11:37 AM, Jean-Paul Calderone wrote: If anything, Twisted's example shows how monolithic packages are easier all-around than micro-packages. We basically have the release infrastructure to release Twisted in many smaller pieces, and we even do - but we only make releases of all the smaller pieces simultaneously, we encourage people to use the "Twisted" package which includes all the pieces, and we don't do any testing of mixed versions of the smaller pieces because it would be very difficult. Micro-packages are really useful when you want to share parts of your technology without forcing adoption of the whole thing. Zope's a good example of this; e.g. zope.interfaces is fabulously useful even if you never use Zope. One of the things we're doing with Launchpad's open source effort is to find those generic useful things that we can split out and distribute separately. https://launchpad.net/~lazr-developers OTOH, once we've exhausted that opportunity, I think we'll be left with a rather large monolithic application. Still useful (I hope) but there won't be much further decomposition into smaller sharable parts. Does Twisted's monolithic package structure stem from a similar pattern? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScq7MXEjvBPtnXfVAQIUFwP/efivE5nTcEF/xhL6FgfJ41/vhWiI1jKY +FNLotOnvNzDVEjwPNBgjLh9AzaX2TMDCBhHXhFJN12bkZ3u1pvbzdc/v/hVJT3X 0tjvJ78JTH/GSu9EBfRPLAbRrTw3JV58HDUlgy1/zETviwerwtU1QN+Tf+v/zH0p NO+OEVgfGPg= =Njrr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 01:29 PM 3/25/2009 -0400, Terry Reedy wrote: Paul Moore wrote: 2009/3/25 Tarek Ziadé : Since setuptools came on the scene, I can state with some certainty that many packages which would otherwise have been distributed as bdist_wininst installers, now aren't. In some cases, only source packages are provided (on the basis that easy_install will build what you need). In those cases, I can accept that maybe the developer would not have built Windows installers even before setuptools arrived. But in a significant number of cases - including setuptools itself - binary, version-specific eggs for Windows are provided, but no bdist_wininst installers. If the developer is willing to build an egg, he could just as easily have built an installer - but he now has to choose - build one or the other, or both. And not everyone chooses the same way. Is it possible to write an egg to bdist converter (or vice versa)? easy_install can convert bdist_wininst installers to .egg files; I'm not sure if the reverse is possible in practice, although it certainly is in principle. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote: I've found setuptools entry points difficult to work with for plugins, I'd be interested in hearing more about your specific difficulties, although it's probably off-topic for Python-Dev. Perhaps via the distutils-sig, since we don't have a plugins sig? ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
At 11:35 AM 3/25/2009 -0500, Olemis Lang wrote: Yes you're right, Trac requires .egg files for local plugins installs (... in /plugins folder ;) so that not all environments but only one be able to use the plugin ... but that's not exactly what I'm saying, since setuptools AFAIK *MUST* be already there ... so Trac depends on setuptools. It depends on pkg_resources, which you can manually extract from the setuptools package if you like. I believe there may be some distros that actually do this, with separate system packages for "setuptools" (really pkg_resources) and setuptools-devel (the setuptools.* code) -- in which case you can have pkg_resources installed without the rest of setuptools being present. > If you install a plugin from source using pip Like you said setuptools is already there ... pip depends on setuptools ... isn't it? Yes, but that doesn't make *Trac* dependent on setuptools, particularly in the system package manager case. > or a system package manager, > no .egg file is involved -- you'll have an .egg-info directory instead, > alongside the installed code. The pkg_resources API for accessing entry > points works with either .egg files or .egg-info directories. > Like I just said setuptools AFAIK *MUST* be there ... isnt it ? Am I still wrong ? Not on the system using the package manager, no. (By 'setuptools' I'm refering to the setuptools.* modules, not the setuptools distribution... which is just another byproduct of our globally confusing terminology for these things.) BTW ... if you (or anyone else ;) suggests me another pkg «like» setuptools (supporting entry points and so on ...) so that I can try how to install and use Trac plugins without setuptools + pkg_* in the middle ... I'll be open to try it out ... and learn a little ;) You'd need pkg_resources, and if you're not using setuptools to initially generate the files to install, you'd have to create the entry point files by hand, following the EggFormats documentation I linked to previously. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote: For case one, where I want to install additional functionality into my system Python interpreter "forever", it would be great to have my system manage this. In fact, I think it /has/ to. I'll go further and say that I'm very wary of using easy_install and the like to install non-distro provided packages into the system Python. Many Linux distros require a functioning system Python to operate and the distros (should) take great care to make sure that if you install package X for application Y, you won't break essential system service Z. Once you start installing your own stuff in the system Python's site-packages, you break the warranty. There was a related problem in previous Ubuntu/Debian releases. If you installed Python from source, say into the default /usr/local and started easy_installing stuff into there, it was possible to break your system Python. This was because the system Python hacked /usr/ local's site-packages into sys.path. That's now been fixed. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScq9ZXEjvBPtnXfVAQLKXwP+K1w1eI8/pdGTzNPZp4McYKPqjgOI2qtm /LzB+g8kHokJNgHDfPu7p6xd5Sc06bQroZ74nqtVhEZKSfSsLkkMKpfH8t5bBeEd bOC7DuqMTMwkTTtAXATCMvY1VsuYBhJQ4Glkgbv1pbmYXE+ogwDsL8sEfjI+YT4m BzsaWPMDIXo= =lvsP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2009, at 6:24 PM, P.J. Eby wrote: At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote: I've found setuptools entry points difficult to work with for plugins, I'd be interested in hearing more about your specific difficulties, although it's probably off-topic for Python-Dev. Perhaps via the distutils-sig, since we don't have a plugins sig? ;-) Yet...? :) Yes, distutils-sig is probably the right place for that discussion. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScq93nEjvBPtnXfVAQKSJwP/XLfRTGecUBk6S4ar/2ODQ1JZ/nIljjHN xbOQ8UKV7V1juv8Z7mrunPYVOd5DlUiv+W8jrmbBI5wtPRATGwuAfuokjkOuWjmF Q93qvzLTs04xhLbKY9JH19YLrsAfV8sZvwxMlit7gGau3lZkySpsrUWFBf0hXEYt PE7kjfFDymM= =Csdq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Barry> In fact, I think it /has/ to. I'll go further and say that I'm Barry> very wary of using easy_install and the like to install Barry> non-distro provided packages into the system Python. Give that man a ceegar. The pyjamas author seems to have a different opinion about installing stuff into /usr without working with the system's packaging mechanism: http://bugs.python.org/setuptools/issue63 I don't understand how that can possibly be manageable. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Ben Finney writes: > And the often-obscured community: those who desperately want the > Python stuff to just behave the same way everything else on their > system does, i.e. be managed approrpiately by the operating system > package manager. A Python-specific packaging system which makes it > harder to fit Python packages into a broader OS policy works very > much at odds with that. À propos, the Debian Python infrastructure team are currently preparing a transition to Python 2.6, with some changes in packaging of distributions using distutils and setuptools. Message-ID: <20090325212256.ge3...@piotro.eu> http://lists.debian.org/msgid-search/20090325212256.ge3...@piotro.eu> -- \ “I do not believe in immortality of the individual, and I | `\consider ethics to be an exclusively human concern with no | _o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Tennessee Leeuwenburg writes: > GSOC? No. This is territory that nobody knows how to mentor yet, ya know? Try it now, and the poor student is likely to find him or herself at the center of a firestorm! Maybe next year ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull wrote: > Tennessee Leeuwenburg writes: > > GSOC? > > No. This is territory that nobody knows how to mentor yet, ya know? > Try it now, and the poor student is likely to find him or herself at > the center of a firestorm! No, we wil > > Maybe next year > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 3:29 AM, Tarek Ziadé wrote: > On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull > wrote: >> Tennessee Leeuwenburg writes: >> > GSOC? >> >> No. This is territory that nobody knows how to mentor yet, ya know? >> Try it now, and the poor student is likely to find him or herself at >> the center of a firestorm! > > No, we wil oups, sent to early sorry -> No, we will hopefully have great PEPs after the language summit tomorrow so the students will be OK ;) There's already a GSOC topic for Disutils about building a distributed test system using PyPI, and I'm hoping to add more topics on packaging after the Summit. Cheers, Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
s...@pobox.com wrote: > Barry> In fact, I think it /has/ to. I'll go further and say that I'm > Barry> very wary of using easy_install and the like to install > Barry> non-distro provided packages into the system Python. > > Give that man a ceegar. The pyjamas author seems to have a different > opinion about installing stuff into /usr without working with the system's > packaging mechanism: > > http://bugs.python.org/setuptools/issue63 > > I don't understand how that can possibly be manageable. > Note that the issue contains a broken link. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Jeff Hall wrote: > Someone asked for the input of "ordinary users" (i.e. non developers) > which, unfortunately, most of the people on this list don't fall in. My > experience with setuptools is that it's poorly documented and assumes a > level of sophistication that isn't always there. While this is fine in a > lot of arenas, installation of things shouldn't be an area where I have > to guess between multiple interpretations of documentation AND have a > thorough knowledge of some of the nuts and bolts of interdependencies. > Maybe having an "easily extensible" language is not consistent with > having an "easy to extend" language, but the current arrangement seems > untenable. I'm mostly reading this thread as an interested observer, but the impression I'm getting is that setuptools and friends are really *packaging tools* (designed to allow developers to communicate information to packagers and distributors) that have been pressed into service as *distribution tools* (designed to deliver software to end users). That is, the full workflow that should really be happening is something like the following: Developer(s) | V (distutils/setuptools/pip/zc.buildout/etc) | V | V Packager(s)/Distributor(s) | V (Windows MSI/Mac OS X bundle/Linux RPM/Linux DEB/etc) | V End User Installation But what appears to be currently happening is that the second half of that process is being skipped in many cases and the "" is instead being used as a substitute for the appropriate platform-specific installation process. This works fine in a centrally hosted web app development world where the "distribution to end users" step essentially amounts to "point your web browser at ". But for other kinds of software that is actually installed on an end user's machine it is going to provide a lousy installation experience. If that perception is accurate, then any changes likely need to focus on the *opposite* end of the toolchain: the part between the "" and the end users. In other words: Given an egg, how easy is it for a packager/distributor to create a platform specific package that places the files in the correct locations for that particular platform (regardless of how arbitrary those rules may appear to the original developers)? Also-not-on-the-right-continent-for-PyCon'ly, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Tools like setuptools, zc.buildout, etc. seem great for developers but not very good for distributions. At last year's Pycon I think there was agreement from the Linux distributors that distutils, etc. just wasn't very useful for them. I think distutils is different here - it not only helps creating distributions (i.e. deployable package files), but also allows direct installation. This, in turn, is used to build the packages for Linux distributions. E.g. debian/rules often contains a "setup.py install" call in its build step (and there is even a CDBS python-distutils.mk fragment) In that sense, distutils is for Python what make is for C. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
>> http://bugs.python.org/setuptools/issue63 >> >> I don't understand how that can possibly be manageable. >> Steve> Note that the issue contains a broken link. Fixed. Looks like a Roundup bug. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan wrote: > Guido van Rossum wrote: >> Please don't do this. We need stable APIs. Trying to switch the entire >> community to use CapWord APIs for something as commonly used as >> datetime sounds like wasting a lot of cycles with no reason except the >> mythical "PEP 8 conformance". As I said, it's a pity we didn't change >> this at the 3.0 point, but I think going forward we should try to be >> more committed to slow change. Additions of new functionality are of >> course fine. But renamings (even if the old names remain available) >> are just noise. > > Even for 3.0, the only API I can recall doing this for was the threading > module, and there we had the additional motivation of being able to add > multiprocessing with only a PEP 8 compliant API while still having it be > close to a drop-in replacement for the corresponding threading API. > > Having helped with that kind of rename once (and for a relatively small > API at that), I'd want a *really* compelling reason before ever going > through it again - it's messy, tedious and a really good way to burn > volunteer time without a great deal to show for it at the end. My first response was "in hindsight we shouldn't have done this." But we moved a bunch of other modules around too (urllib, http, db, I forget what else) and I think those worked out well. Why was threading particularly unpleasant? (An no, this isn't a rhetorical question or a retort. I'm just curious -- I have the same feeling but can't pin it down.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Mar 25, 2009, at 5:25 AM, Antoine Pitrou wrote: Paul Moore gmail.com> writes: 3. Setuptools, unfortunately, has divided the Python distribution community quite badly. Wait a little bit, and it's gonna be even worse, now that buildout and pip seem to become popular. For example, the TurboGears people are considering switching from setuptools to pip... Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but I'm not sure it'll be enough to stop people from converting to whatever of the many build/packaging systems which have been popping up recently. Combined with the current trend that everything must be exploded into lots of interdependent but separately packaged libraries (the paste/pylons syndrome... try pulling something like TurboGears2 and see how many third-party packages it installs), I fear this is going to generate a very painful user/developer experience :-( From my perspective (the Python web community), setuptools has been a great uniter of community. By making it easier to break-up large projects into smaller distributions, it's now reasonable to share more code between more developers. This is an important philosophy of TurboGears 2, in that they're bringing together different pieces of Python web parts and composing them into a single framework. I think it's great that when I'm working on a Zope-based project I can participate in packages produced by the non-Zope ecosystem. This builds much greater bridges across sub-communites than smaller barriers put up such as one project using pip and another using easy_install. Heck, even when only wanting to share code between a couple personal projects, the barrier is now low enough that it's reasonable to package up that code and share a distribution, when in the past the only way to share that code was nasty copy-n-paste. Yes, there is pain in learning to use these tools, but it's mostly a documentation issue. Once you've learned the tools, it can be very easy to manage a very large amount of packages. Thanks to Buildout (luv the Buildout!) it's so much easier today to deploy a Zope- based application today than it was 5 years ago, even though a Zope- based application 5 years ago used a single monolithic Zope distribution and a Zope-based application today is composed of many, many smaller distributions. I'm very happy that I can so easily incorporate 3rd party libraries into my projects, it makes for a very pleasant developer experience :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Packaging Survey first results + Summit schedule
Hi, Sorry for the cross-post, but it seemed appropriate since packaging is being discussed in python-dev tonight, - Here are the first results for the packaging survey: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ - And tomorrow's Summit schedule for the packaging part : http://tarekziade.wordpress.com/2009/03/26/pycon-language-summit-is-tomorrow/ Please comment (in the appropriate list or in my blog) if you have something you would like to say or see addressed during the Summit and you are unable to be present. (I am already trying to summarize what has been said in python-dev today but I am not sure I'll be able to read everything before tomorrow) Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote: > If that perception is accurate, then any changes likely need to focus on > the *opposite* end of the toolchain: the part between the " packaging spec>" and the end users. Yes - but is this part the job of python ? > In other words: Given an egg, how easy is it for a packager/distributor > to create a platform specific package that places the files in the > correct locations for that particular platform (regardless of how > arbitrary those rules may appear to the original developers)? Why coming from eggs and not from the build tool provided by python itself (distutils) ? I don't see what eggs brings - specially since the format is not even standardized. cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things done rather than an end goal
in itself. I agree that the motivation and the comparison should be
added to the PEP (perhaps moving the trampoline sample
*implementation* to a reference or an appendix, since it is only the
appearance of the trampoline-*using* code that matters).
--Guido
On Wed, Mar 25, 2009 at 7:26 AM, P.J. Eby wrote:
> At 06:03 PM 3/25/2009 +1200, Greg Ewing wrote:
>>
>> I wanted a way of writing suspendable functions that
>> can call each other easily. (You may remember I
>> originally wanted to call it "call".) Then I noticed
>> that it would also happen to provide the functionality
>> of earlier "yield from" suggestions, so I adopted that
>> name.
>
> I still don't see what you gain from making this syntax, vs. putting
> something like this in the stdlib (rough sketch):
>
> class Task(object):
> def __init__(self, geniter):
> self.stack = [geniter]
>
> def __iter__(self):
> return self
>
> def send(self, value=None):
> if not self.stack:
> raise RuntimeError("Can't resume completed task")
> return self._step(value)
>
> send = next
>
> def _step(self, value=None, exc_info=()):
> while self.stack:
> try:
> it = self.stack[-1]
> if exc_info:
> try:
> rv = it.throw(*exc_info)
> finally:
> exc_info = ()
> elif value is not None:
> rv = it.send(value)
> else:
> rv = it.next()
> except:
> value = None
> exc_info = sys.exc_info()
> if exc_info[0] is StopIteration:
> exc_info = () # not really an error
> self.pop()
> else:
> value, exc_info = yield_to(rv, self)
> else:
> if exc_info:
> raise exc_info[0], exc_info[1], exc_info[2]
> else:
> return value
>
> def throw(self, *exc_info):
> if not self.stack:
> raise RuntimeError("Can't resume completed task")
> return self._step(None, exc_info)
>
> def push(self, geniter):
> self.stack.append(geniter)
> return None, ()
>
> def pop(self, value=None):
> if self.stack:
> it = self.stack.pop()
> if hasattr(it, 'close'):
> try:
> it.close()
> except:
> return None, sys.exc_info()
> return value, ()
>
> �...@classmethod
> def factory(cls, func):
> def decorated(*args, **kw):
> return cls(func(*args, **kw))
> return decorated
>
>
> def yield_to(rv, task):
> # This could/should be a generic function, to allow yielding to
> # deferreds, sockets, timers, and other custom objects
> if hasattr(rv, 'next'):
> return task.push(rv)
> elif isinstance(rv, Return):
> return task.pop(rv.value)
> else:
> return rv, ()
>
> class Return(object):
> def __init__(self, value=None):
> self.value = value
>
>
> @Task.factory
> def sample_task(arg1, another_arg):
> # blah blah
> something = (yield subtask(...))
>
> yield Return(result)
>
> def subtask(...):
> ...
> yield Return(myvalue)
>
>
> The trampoline (the _step() method) handles the co-operative aspects, and
> modifying the yield_to() function allows you to define how yielded values
> are processed. By default, they're sent back into the generator that yields
> them, but you can pass a Return() to terminate the generator and pass the
> value up to the calling generator. Yielding another generator, on the other
> hand, "calls" that generator within the current task, and the same rules
> apply.
>
> Is there some reason why this won't do what you want, and can't be modified
> to do so? If so, that should be part of the PEP, as IMO it otherwise lacks
> motivation for a language feature vs. say, a stdlib module. If 'yield_to'
> is a generic function or at least supports registration of some kind, a
> feature like this would be interoperable with a wide variety of frameworks
> -- you could register deferreds and delayed calls and IO objects from
> Twisted, for example. So it's not like the feature would be creating an
> entire new framework of its own. Rather, it'd be a front-end to whatever
> framework (or no framework) you're using.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote: > Greg Ewing wrote: >> Would you be happier if some syntactic way to do that >> were provided? >> >> It could perhaps be done by enhancing the part of the >> 'for' loop that gets executed upon normal termination >> of the iterator. >> >> for x in my_iter: >> do_something_with(x) >> else v: >> handle_return_value(v) > > I think something like that would actually make the PEP much stronger on > this front - it would promote the idea of a "final value" for iterators > as a more fundamental concept that can be worked with in a non-generator > context. Hold it right there. Or maybe I should say "in your dreams." Please don't stretch the scope of the PEP. It's not going to help your cause. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
On Thu, Mar 26, 2009 at 12:26 PM, "Martin v. Löwis" wrote: >> Tools like setuptools, zc.buildout, etc. seem great for developers but not >> very good for distributions. At last year's Pycon I think there was >> agreement from the Linux distributors that distutils, etc. just wasn't very >> useful for them. > > I think distutils is different here - it not only helps creating > distributions (i.e. deployable package files), but also allows > direct installation. This, in turn, is used to build the packages > for Linux distributions. E.g. debian/rules often contains a > "setup.py install" call in its build step (and there is even a > CDBS python-distutils.mk fragment) > > In that sense, distutils is for Python what make is for C. It is more like the whole autotools suite (at least for unix), and that's the problem: distutils does everything quite poorly, and once you need to do something that distutils can't do out of the box, you are in a no man's land because distutils is almost impossible to extend (everything is done internally, with no way to recover data short of rewriting everything or monkey patching). To take a recent example, I wanted to add the ability to install a clib extension (pure C, no python API), so that it can be used by other projects: that would take 2 minutes with any build tool out there, but is almost impossible in distutils, unless you rewrite your own build_clib and/or install commands. Even autotools is more enjoyable, which is quite an achievement :) If distutils was split into different modules (one for the build, one for the compiler/platform configuration, one for the installation), which could be extended, tweaked, it would be much better. But the distutils design makes this inherently very difficult (commands). cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Tue, Mar 24, 2009 at 11:03 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> The way I think of it, that refactoring has nothing to do with >> yield-from. > > I'm not sure what you mean by that. Currently it's > *impossible* to factor out code containing a yield. That's stating it a little too strongly. Phillip has shown how with judicious use of decorators and helper classes you can get a reasonable approximation, and I think Twisted uses something like this, so it's not just theory. I think the best you can do without new syntax though is still pretty cumbersome and brittle, which is why I have encouraged your PEP. > Providing a way to do that is what led me to invent > this particular version of yield-from in the first > place. > > I wanted a way of writing suspendable functions that > can call each other easily. (You may remember I > originally wanted to call it "call".) Then I noticed > that it would also happen to provide the functionality > of earlier "yield from" suggestions, so I adopted that > name. > > But for me, factorability has always been the fundamental > idea, and the equivalence, in one particular restricted > situation, to a for loop containing a yield is just a > nice bonus. > > That's what I've tried to get across in the PEP, and > it's the reason I've presented things in the way I have. That's all good. I just don't think that a presentation in terms of code in-lining is a good idea. That's not how we explain functions either. We don't say "the function call means the same as when we wrote the body of the function in-line here." It's perhaps a game with words, but it's important to me not to give that impression, since some languages *do* work that way (e.g. macro languages and Algol-60), but Python *doesn't*. >> It's not just variable references -- I used "scope" as a >> shorthand for everything that can be done within a function body, >> including control flow: try/except/finally, >> continue/break/raise/return. > > Same answer applies -- use the usual techniques. > > When I talk about inlining, I mean inlining the > *functionality* of the code, not its literal text. I'm > leaving the reader to imagine performing the necessary > transformations to preserve the semantics. Yeah, so I'm asking you to use a different word, since "inlining" to me has pretty strong connotations of textual substitution. >> Maybe you're confusing motivation with explanation? That feedback >> seems to tell me that the *motivation* needs more work; but IMO the >> *explanation* should start with this simple model and then expand upon >> the edge cases. > > Perhaps what I should do is add a Motivation section before > the Proposal and move some of the material from the beginning > of the Rationale sectiomn there. Yeah, I think it can easily be saved by changing the PEP without changing the specs of the proposal. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote: > On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote: > >> If that perception is accurate, then any changes likely need to focus on >> the *opposite* end of the toolchain: the part between the "> packaging spec>" and the end users. > > Yes - but is this part the job of python ? > >> In other words: Given an egg, how easy is it for a packager/distributor >> to create a platform specific package that places the files in the >> correct locations for that particular platform (regardless of how >> arbitrary those rules may appear to the original developers)? I think Distutils (and therefore Setuptools) should provide some APIs to play with special files (like resources) and to mark them as being special, no matter where they end up in the target system. So the code inside the package can use these files seamessly no matter what the system is and no matter where the files have been placed by the packager. This has been discussed already but not clearly defined. > > Why coming from eggs and not from the build tool provided by python > itself (distutils) ? I don't see what eggs brings - specially since > the format is not even standardized. I don't think the "egg as a format" part has anything to do with this discussion. It's just a zip file with a specific layout. What's important is what we store in the .egg-info directory (or file) which has two standards today (one in Distutils, one in Setuptools) but wich should get a common standard soon (PEP 376) Cheers Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Guido van Rossum wrote: > On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan wrote: >> Having helped with that kind of rename once (and for a relatively small >> API at that), I'd want a *really* compelling reason before ever going >> through it again - it's messy, tedious and a really good way to burn >> volunteer time without a great deal to show for it at the end. > > My first response was "in hindsight we shouldn't have done this." Even in hindsight, I think our reasons for providing a PEP 8 compliant threading API are sound. But the experience still makes me cautious of doing it again. > But > we moved a bunch of other modules around too (urllib, http, db, I > forget what else) and I think those worked out well. For everything else, we just changed the module name or location. The test suite is pretty good at finding any relevant imports that need to be fixed, and 2to3 is also pretty good at handling them for third party code. The threading module was different in that we actually wanted to change the API of the module itself rather than just where to find it. > Why was threading > particularly unpleasant? (An no, this isn't a rhetorical question or a > retort. I'm just curious -- I have the same feeling but can't pin it > down.) I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API. The difficulty of that decision strongly flavours my recollection of the whole process even though the final solution chosen was quite simple (maintain the two APIs in parallel, with a couple of notes in the documentation about the situation). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: > On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote: >> It could perhaps be done by enhancing the part of the >>> 'for' loop that gets executed upon normal termination >>> of the iterator. >>> >>> for x in my_iter: >>> do_something_with(x) >>> else v: >>> handle_return_value(v) >> I think something like that would actually make the PEP much stronger on >> this front - it would promote the idea of a "final value" for iterators >> as a more fundamental concept that can be worked with in a non-generator >> context. > > Hold it right there. Or maybe I should say "in your dreams." Please > don't stretch the scope of the PEP. It's not going to help your cause. Yes, I now agree your suggestion of comparing and contrasting with PJE's simple trampoline example is a much better angle of attack. Although the PEP may still want to mention how one would write *tests* for these things. Will the test drivers themselves need to be generators participating in some kind of trampoline setup? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
On Thu, Mar 26, 2009 at 5:32 AM, David Cournapeau wrote: > If distutils was split into different modules (one for the build, one > for the compiler/platform configuration, one for the installation), > which could be extended, tweaked, it would be much better. But the > distutils design makes this inherently very difficult (commands). I am not sur why the command design is a problem here. And I think Distutils features are not far from what you need, if you look at things like customize_compiler, which is called by build_clib. I'm ready to discuss your use case in Distutils-SIG, if you have a complete example etc. Cheers Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
Tarek Ziadé wrote: > On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote: >> Why coming from eggs and not from the build tool provided by python >> itself (distutils) ? I don't see what eggs brings - specially since >> the format is not even standardized. > > I don't think the "egg as a format" part has anything to do with this > discussion. It's just a zip file with > a specific layout. > > What's important is what we store in the .egg-info directory (or file) which > has two standards today (one in Distutils, one in Setuptools) but wich should > get a common standard soon (PEP 376) Yes, that metadata is what I meant to refer to rather than zipped .egg files specifically. An egg is just one example of something which includes that metadata. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
On Thu, Mar 26, 2009 at 2:01 PM, Tarek Ziadé wrote: > On Thu, Mar 26, 2009 at 5:32 AM, David Cournapeau wrote: >> If distutils was split into different modules (one for the build, one >> for the compiler/platform configuration, one for the installation), >> which could be extended, tweaked, it would be much better. But the >> distutils design makes this inherently very difficult (commands). > > I am not sur why the command design is a problem here. For several reasons: - options handling cannot be done correctly. If you need to pass some options specific to the build, you have to pass it to build_clib and build_ext, etc... Example: I would really like to add options like --with-libfoo ala autoconf so that the packager can simply say where to look for a library (headers, .so, etc). This cannot be done easily in distutils (no persistence, no easy way to communicate between commands) - the whole concept of commands is bogus for a build tool. The correct way to do builds is with a DAG, to handle dependencies. > And I think > Distutils features are not far from > what you need, if you look at things like customize_compiler, which is > called by build_clib. The whole customize_compiler is awful. You cannot call it when you want, but only at some arbitrary time in the execution, which is not documented. You have to create your own command, because you can't call it in setup.py directly. You may have to call initialize_something_which_has_nothing_to_do_with_compiler(), which may break on windows because the MS compiler abstraction is totally different than the unix one. It is actually hard to believe if you never had to deal with it: so many trivial things which are one line of code in every other tool are difficult, obscure, magic or damn impossible in distutils. Modifiying compiler flag ? You have to create a new compiler class. Installing docs ? You have to create your own install class. etc... > > I'm ready to discuss your use case in Distutils-SIG, if you have a > complete example etc. Ok, I will give you the example on the distutils ML, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 2:01 PM, Nick Coghlan wrote: > Yes, that metadata is what I meant to refer to rather than zipped .egg > files specifically. An egg is just one example of something which > includes that metadata. Ok, my bad. Being able to describe meta-data for installed files is indeed sorely needed, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
David Cournapeau writes: > On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote: > > > If that perception is accurate, then any changes likely need to focus on > > the *opposite* end of the toolchain: the part between the " > packaging spec>" and the end users. > > Yes - but is this part the job of python ? Yes. In the sense that what I'm hearing from this discussion is that tools that are very satisfactory for the upstream end of the chain can often result in formats that are inconvenient for some downstream end. Even if the downstream end doesn't use it, some of their users may mix that into their own installation, and it's difficult for anyone to sort the resulting mess. Ie, Python may not be resposible for that distribution or its format, but Python should take care not to kick up sand that may blow into downstream's gearbox. > Why coming from eggs Or other complex format? Well, because downstream consumers will want them. Nick's point is that there are multiple consumers of Python distributions. So we have a toolchain +-> E --> downstream developer -+ | | | +--+ V source -> build -> A -> B -+-> C -> D -> | END USER | <+ | +--+ A | | +-> F -> OS distro -+ I think the point is to push the B -> C or E or F split point as far downstream as possible ... but no farther. As I understand his request for "focus on the opposite end", it's that. He's not claiming that a one-size-fits all linear distribution chain is possible. Rather, he's asking that we ask that very question: is there an existing format that would be a better place to split? If so, then the stdlib should be built on top of that format, and it should be a standard part of Python. But what we have so far is people are saying "of course if you do it my way everything will work out fine", but then they're left waving their hands and chanting spells when it comes to being concrete about how their vaporware PMS will satisfy the needs of the other camps. So there's a need to analyze the requirements of downstream library developers, workstation app developers, web developers, end users, and OS distros (I hope I haven't left anybody out). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "setuptools has divided the Python community"
On Thu, Mar 26, 2009 at 2:42 PM, Stephen J. Turnbull wrote: > > +-> E --> downstream developer -+ > | | > | +--+ V > source -> build -> A -> B -+-> C -> D -> | END USER | <+ > | +--+ A > | | > +-> F -> OS distro -+ > According to your diagram, the build->A is the only part where describing meta-data can be possible so that everyone benefit from it - which is what I believe Tarek is working on, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
