Re: [Distutils] zc.buildout and "System Python"
On Thu, Oct 28, 2010 at 12:26 PM, Barry Warsaw wrote: > On Oct 28, 2010, at 12:08 PM, Jim Fulton wrote: > >>BTW, I really don't care about certain types of innovation (e.g. file >>locations, wide unicode) as long as I as a developer don't feel them. >>It occurs to me that it would be useful if there was a definition of a >>standard Python that provided a baseline that developers could count >>on. Today, the closest thing to a standard is the Python distribution. >>I suppose that doesn't have to be the standard. Of course, defining >>such a standard might be really painful, especially via email. It might >>be a good PyCon discussion/sprint topic. > > We should do this. Let's do it! :) ... > But maybe there's still something we can do here. We should put this on the > agenda for Pycon. Not sure what that involves. > Would the language summit be an appropriate forum (at least > as a start)? I think it would be a good idea to at least mention it there. I'm not sure all of the interested people will be there. Jim -- Jim Fulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Thu, Oct 28, 2010 at 12:08:30PM -0400, Jim Fulton wrote: > On Thu, Oct 28, 2010 at 11:47 AM, Toshio Kuratomi wrote: > > On Thu, Oct 28, 2010 at 10:22:58AM -0400, Jim Fulton wrote: > >> > >> It occurs to me that it would be nice if we made clean Python > >> packages available for some of the popular Unix platforms. I'm not > >> sure what would be involved in doing that, from a distribution point > >> of view. > >> > > If you're talking about a python that is carried by the OS in their package > > sets, updatable using the OS tools, etc > > That would be great. It might be enough to post pre-built packages. > There's a few ways to achieve that as well and it would be a lot simpler. There's the opensuse build system which lets you build packages for a variety of distributions. There's ubuntu ppas and fedora personal repos that let you host within the distributions namespace but are marked as being separate... Lots of different options there that might be suitable. > > catch me on IRC (abadger1999 on > > irc.freenode.net) and we could talk about this. Off the top of my head, > > I think it would be possible with a few compromises but not easy in the > > decision department. > > Which makes it unattractive. I'm really not interested in getting > embroiled in a political process. > If going the route of getting a "clean python" into the distributions themselvs, there's going to be a good deal of politics as there are a lot of hard questions to answer there and a lot of contrary goals to reconcile. The idea of simply hosting package repositories for each distribution would be a lot easier in this area. > BTW, I really don't care about certain types of innovation (e.g. file > locations, wide unicode) as long as I as a developer don't feel them. > It occurs to me that it would be useful if there was a definition of a > standard Python that provided a baseline that developers could count > on. Today, the closest thing to a standard is the Python distribution. > I suppose that doesn't have to be the standard. Of course, defining > such a standard might be really painful, especially via email. It might > be a good PyCon discussion/sprint topic. > That could be a productive definition. > > The biggest issue I see is that it wouldn't be possible to fix bugs in > > these packages. Perhaps it would be possible to compromise and fix bugs but > > only when the patches are backports from the upstream repository > > I'm not sure what you mean. Bugs are fixed via Python distributions. > Is this not fast enough? > Correct, it's not fast enoguh. Many distributions move imuch faster than python releases. Even slow moving distributions can simply be releasing/releasing updates out of sync with when python itself releases. As an example, Fedora releases a new version every six months. Each release has a 13 month lifetime. During the 13 month lifetime, Fedora releases updated packages almost daily. So if someone filed a bug that python-2.7.1-1 had a segfault or a UnicodeError or some other bug that the maintainer felt was worthwhile to fix in the released Fedora, they would ship an updated python package (perhaps with a backport from python-2.x's tree or perhaps by coding a fix and then submitting the fix upstream afterwards) and make the update as soon as they felt they had a workable solution. > > but we > > presently do that in Fedora for firefox/xulrunner/thunderbird because of > > mozilla's trademark agreement and it causes no end of conflicts between > > contributors. > > I assume that wouldn't be a problem for Python, assuming I have a clue > what that is. :) > Well -- the causitive agent is different but the results are similar. In mozilla's case, the issue is adding code that mozilla doesn't endorse as with their permission you have to abandon the trademarks. In a "clean python"'s case, it would be that we want to enforce on ourselves to only ship what's in upstream. In both cases, it prevents fixing bugs and making other changes ahead of an external (to the distribution) schedule. -Toshio pgp8OpvpQEaG2.pgp Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Oct 28, 2010, at 12:08 PM, Jim Fulton wrote: >BTW, I really don't care about certain types of innovation (e.g. file >locations, wide unicode) as long as I as a developer don't feel them. >It occurs to me that it would be useful if there was a definition of a >standard Python that provided a baseline that developers could count >on. Today, the closest thing to a standard is the Python distribution. >I suppose that doesn't have to be the standard. Of course, defining >such a standard might be really painful, especially via email. It might >be a good PyCon discussion/sprint topic. We should do this. The "System Python" has too many competing OS-specific constraints that pretty much ensure it will always be idiosyncratic. FWIW, in Debian/Ubuntu, we're at least trying to *document* some of those issues: http://wiki.debian.org/Python I'm supportive of an effort to define "Clean Python" as a separate "thing" that you can install in parallel and use as a better base for your third party application deployment. To be most useful, I think this should be as similar and predictable as possible across distributions. Of course, it gets harder still when you want to extend that to cross-OS/platform. But maybe there's still something we can do here. We should put this on the agenda for Pycon. Would the language summit be an appropriate forum (at least as a start)? -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Thu, Oct 28, 2010 at 11:47 AM, Toshio Kuratomi wrote: > On Thu, Oct 28, 2010 at 10:22:58AM -0400, Jim Fulton wrote: >> >> It occurs to me that it would be nice if we made clean Python >> packages available for some of the popular Unix platforms. I'm not >> sure what would be involved in doing that, from a distribution point >> of view. >> > If you're talking about a python that is carried by the OS in their package > sets, updatable using the OS tools, etc That would be great. It might be enough to post pre-built packages. > catch me on IRC (abadger1999 on > irc.freenode.net) and we could talk about this. Off the top of my head, > I think it would be possible with a few compromises but not easy in the > decision department. Which makes it unattractive. I'm really not interested in getting embroiled in a political process. BTW, I really don't care about certain types of innovation (e.g. file locations, wide unicode) as long as I as a developer don't feel them. It occurs to me that it would be useful if there was a definition of a standard Python that provided a baseline that developers could count on. Today, the closest thing to a standard is the Python distribution. I suppose that doesn't have to be the standard. Of course, defining such a standard might be really painful, especially via email. It might be a good PyCon discussion/sprint topic. > The biggest issue I see is that it wouldn't be possible to fix bugs in > these packages. Perhaps it would be possible to compromise and fix bugs but > only when the patches are backports from the upstream repository I'm not sure what you mean. Bugs are fixed via Python distributions. Is this not fast enough? > but we > presently do that in Fedora for firefox/xulrunner/thunderbird because of > mozilla's trademark agreement and it causes no end of conflicts between > contributors. I assume that wouldn't be a problem for Python, assuming I have a clue what that is. :) Jim -- Jim Fulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Thu, Oct 28, 2010 at 10:22:58AM -0400, Jim Fulton wrote: > > It occurs to me that it would be nice if we made clean Python > packages available for some of the popular Unix platforms. I'm not > sure what would be involved in doing that, from a distribution point > of view. > If you're talking about a python that is carried by the OS in their package sets, updatable using the OS tools, etc catch me on IRC (abadger1999 on irc.freenode.net) and we could talk about this. Off the top of my head, I think it would be possible with a few compromises but not easy in the decision department. For instance, distributions have rules such as "don't bundle libraries that are available on the system" that would apply to things like libffi which are built from within python by default. Or the use of wide-unicode which isn't the default in a vanilla upstream build but is the default on the Linux distributions that I know of. Or the use of multilib which makes for a split directory layout for libraries instead of a single location. The biggest issue I see is that it wouldn't be possible to fix bugs in these packages. Perhaps it would be possible to compromise and fix bugs but only when the patches are backports from the upstream repository but we presently do that in Fedora for firefox/xulrunner/thunderbird because of mozilla's trademark agreement and it causes no end of conflicts between contributors. -Toshio pgp5s6xOBkCEd.pgp Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Mon, Oct 25, 2010 at 4:53 AM, Eric Lemoine wrote: > Hi > > I'm currently switching to zc.buildout 1.5. I've been looking at > having a Python environment that is fully isolated from the main, > system-wide Python environment. > > Can you confirm that zc.buildout 1.5 supports that? That depends on what exactly "that" is. The easiest way to have "a Python environment that is fully isolated from the main, system-wide Python environment" is to have a separate build. > Does this imply working with a "System Python"? buildout 1.5 *tries* to coexist with system Python installations. > The term "System Python" confuses me a bit, as what I want is an > environment that is isolated from the system-wide Python environment? > So could someone please explain what a "System Python" refers to > exactly? Maybe we should use a different term, but "System Python" is a euphemism for a Python that has been packaged by an OS packager. For better or worse, these packagers tend to be innovative and deliver Python installations that differ from a from-source build in unpredictable ways. This could involve additions, omissions, or specialized build options. Buildout 1.5 tries to coexist with system Pythons by hiding additions in site-packages (or the innovative equivalent). Virtualenv does something similar. I use the term "clean python" to refer to a Python installation based on a straightforward build from source, and without any site-local packages in it's site-packages directory. (Where straightforward is a euphemism for a build after making sure that certain system libraries, such as zlib, are available where Python can find them.) We here at ZC package these installs as RPMs that are available system wide along side the "system Python". I tell all my friends to use clean Python's for anything important. > Also, the doc says: "Using a system Python is inherently fragile. Yes. > Using a clean, freshly-installed Python without customization in > site-packages is more robust and repeatable". Does this mean using a > "System Python" isn't recommended for production? Yes. That's what it means. > And how can use a > "clean, freshly-installed Python"? What's a "clean, freshly-installed > Python" anyway? "freshly installed" is irrelevent, otherwise see above. > Again, what I'm after is a Python environment that is fully isolated > from the system-wide Python, just like virtualenv --no-site-packages > provides? The only way to get a Python that is fully isolated from another Python install is to build one yourself from source. Note: - "System-wide" isn't really relevent. What's important is a predictable install, which I choose to define as one you'd get from a source build, without special additions or omissions. You can have a clean Python that is installed system wide. Theoretically, system packages could provide clean Pythons, although I've never seen one. It occurs to me that it would be nice if we made clean Python packages available for some of the popular Unix platforms. I'm not sure what would be involved in doing that, from a distribution point of view. - "virtualenv --no-site-packages" doesn't give you complete isolation. In particular, it doesn't protect you from omissions. Jim -- Jim Fulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
Hi Eric, From my understanding, it's officially supported by buildout, but the problem is that the recipe should support it too. Then, depending of which recipe you are using, you have to make sure it support it. There's a flag you can use for that, as somebody told on this list: See http://pypi.python.org/pypi/zc.buildout#working-with-a-system-python, especially the bits about include-site-packages = false and exec-sitecustomize = false. Tell me if it work well on your side... mathieu On Wed, Oct 27, 2010 at 6:07 PM, Eric Lemoine wrote: > On Mon, Oct 25, 2010 at 10:53 AM, Eric Lemoine > wrote: >> Hi >> >> I'm currently switching to zc.buildout 1.5. I've been looking at >> having a Python environment that is fully isolated from the main, >> system-wide Python environment. >> >> Can you confirm that zc.buildout 1.5 supports that? >> >> Does this imply working with a "System Python"? >> >> The term "System Python" confuses me a bit, as what I want is an >> environment that is isolated from the system-wide Python environment? >> So could someone please explain what a "System Python" refers to >> exactly? >> >> Also, the doc says: "Using a system Python is inherently fragile. >> Using a clean, freshly-installed Python without customization in >> site-packages is more robust and repeatable". Does this mean using a >> "System Python" isn't recommended for production? And how can use a >> "clean, freshly-installed Python"? What's a "clean, freshly-installed >> Python" anyway? >> >> Again, what I'm after is a Python environment that is fully isolated >> from the system-wide Python, just like virtualenv --no-site-packages >> provides? > > > Noone can help me with this question? Thanks, > > > > -- > Eric Lemoine > > Camptocamp France SAS > Savoie Technolac, BP 352 > 73377 Le Bourget du Lac, Cedex > > Tel : 00 33 4 79 44 44 96 > Mail : eric.lemo...@camptocamp.com > http://www.camptocamp.com > ___ > Distutils-SIG maillist - distutils-...@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Mathieu Leduc-Hamel ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zc.buildout and "System Python"
On Mon, Oct 25, 2010 at 10:53 AM, Eric Lemoine wrote: > Hi > > I'm currently switching to zc.buildout 1.5. I've been looking at > having a Python environment that is fully isolated from the main, > system-wide Python environment. > > Can you confirm that zc.buildout 1.5 supports that? > > Does this imply working with a "System Python"? > > The term "System Python" confuses me a bit, as what I want is an > environment that is isolated from the system-wide Python environment? > So could someone please explain what a "System Python" refers to > exactly? > > Also, the doc says: "Using a system Python is inherently fragile. > Using a clean, freshly-installed Python without customization in > site-packages is more robust and repeatable". Does this mean using a > "System Python" isn't recommended for production? And how can use a > "clean, freshly-installed Python"? What's a "clean, freshly-installed > Python" anyway? > > Again, what I'm after is a Python environment that is fully isolated > from the system-wide Python, just like virtualenv --no-site-packages > provides? Noone can help me with this question? Thanks, -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] zc.buildout and "System Python"
Hi I'm currently switching to zc.buildout 1.5. I've been looking at having a Python environment that is fully isolated from the main, system-wide Python environment. Can you confirm that zc.buildout 1.5 supports that? Does this imply working with a "System Python"? The term "System Python" confuses me a bit, as what I want is an environment that is isolated from the system-wide Python environment? So could someone please explain what a "System Python" refers to exactly? Also, the doc says: "Using a system Python is inherently fragile. Using a clean, freshly-installed Python without customization in site-packages is more robust and repeatable". Does this mean using a "System Python" isn't recommended for production? And how can use a "clean, freshly-installed Python"? What's a "clean, freshly-installed Python" anyway? Again, what I'm after is a Python environment that is fully isolated from the system-wide Python, just like virtualenv --no-site-packages provides? Thanks for any answer, -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
