Re: [Repoze-dev] BFG and GAE
On 2010-05-05, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 05.05.2010, 17:10 Uhr, schrieb Alex Clark acl...@aclark.net: However I'll mention I see guys like philikon (http://i-luuv.appspot.com) and davisagli (http://buildthreat.appspot.com/) building cool apps on GAE and I can't help but wonder what it would be like if the BFG/GAE story was complete and in place. Please forgive the ignorance but is actually cool about those two sites? Heh, just that you can knock together scalable toy apps for fun. In the case of philikon's http://i-luuv.appspot.com/ he used WebOb and some HTML5 IIRC, and davisagli appears to have used straight Python: http://pypi.python.org/pypi/buildout.threatlevel Charlie -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] BFG and GAE
Hi all, I am just going to blurt this out because I am thinking about it. At last night's Python Meetup Tres mentioned something about their being various ways to use BFG on GAE… which makes me wonder: what would it take to get GAE support from the top down? I'm sure I already know the answer (well, I'll guess anyway): there is no immediate Agendaless (or any other big BFG shop) customer need for it, so it's not going to happen until there is. Fair enough (we all know/understand how that works). Which brings me to an actual question: is marketing BFG on GAE even desirable by the community? In other words, is making it work on a platform that has wide-spread adoption like GAE (I assume it has widespread adoption) something folks are interested in as a way to spread the word and inject new developers/users into the project? Or am I just blinded by shiny toys too much. I suspect the latter ;-) However I'll mention I see guys like philikon (http://i-luuv.appspot.com) and davisagli (http://buildthreat.appspot.com/) building cool apps on GAE and I can't help but wonder what it would be like if the BFG/GAE story was complete and in place. 2cents, Thanks for reading, Alex -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG and GAE
On 2010-05-05, Chris McDonough chr...@plope.com wrote: On Wed, 2010-05-05 at 15:10 +, Alex Clark wrote: Hi all, I am just going to blurt this out because I am thinking about it. At last night's Python Meetup Tres mentioned something about their being various ways to use BFG on GAE… which makes me wonder: what would it take to get GAE support from the top down? I assume by top down, you mean the principals of BFG consider it a preferred deployment platform. Right, really I just meant implemented by the core devs vs. contributed but close enough. I hadn't even thought about whether BFG would have to compromise its principals to run on GAE… and I assume that it wouldn't. I'm sure I already know the answer (well, I'll guess anyway): there is no immediate Agendaless (or any other big BFG shop) customer need for it, so it's not going to happen until there is. Fair enough (we all know/understand how that works). Which brings me to an actual question: is marketing BFG on GAE even desirable by the community? In other words, is making it work on a platform that has wide-spread adoption like GAE (I assume it has widespread adoption) something folks are interested in as a way to spread the word and inject new developers/users into the project? Or am I just blinded by shiny toys too much. I suspect the latter ;-) However I'll mention I see guys like philikon (http://i-luuv.appspot.com) and davisagli (http://buildthreat.appspot.com/) building cool apps on GAE and I can't help but wonder what it would be like if the BFG/GAE story was complete and in place. I consider it useful for BFG to run on the widest variety of platforms possible. It should run within reason on an arbitrary system independent of Python version (2.4, 2.5, 2.6, 2.7.. although not 3.X yet), Python implementation (CPython/GAE/Jython... and untested but hopefully IronPython), and operating system (UNIX/Windows/GAE). This is both a practical and a marketing issue. On the practical side, being able to use the tool in many contexts is useful (e.g. alongside Plone 3 in a Python 2.4 deployment, or on GAE for a simple app). On the marketing side, we have spikes in interest and we gain new users whenever we put BFG into one of these contexts (e.g. a blog entry BFG on Jython, or BFG on GAE etc). So to the extent that it helps market BFG, I'm all for better GAE support, and I would *love* to see people blog about putting BFG apps on GAE and other alternate platforms. There's only a single caveat: adding support for one platform cannot detract from the portability of BFG onto other platforms. Other than that, I'd love to see add-ons for BigTable bindings, authentication, etc that targeted GAE specifically, as well as IronPython, Jython, etc. Wrt GAE specifically, from a personal perspective, I like the idea of its easy deployment, but the kinds of work Agendaless does doesn't really lend itself to deployment on GAE due to limitations of the platform. So business-wise it will probably not become a preferred deployment platform for *Agendaless*. As a result, it will really need to be someone else who takes up the mantle of making BFG better on GAE. That said, this isn't an I don't care, this is an I care, but someone else is going to have to care more. Right, this all makes sense, thanks. As far as limitations of the platform goes, is this a cloud computing vs. traditional model issue? Or is it a GAE-specific thing. I suspect the latter because it seems any framework that runs on their (GAE's) platform has to bend itself to fit. Whereas something like Ian's Silver Lining (which also excites me) might make a better cloud deployment story for BFG. Alex - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On 2010-04-26, Chris Withers ch...@simplistix.co.uk wrote:
I don't believe this to be the case, so I dropped Fred a mail.
Here's his response:
Fredrik Lundh wrote:
Hi Chris, thanks for the heads up.
Not sure what's going on here; PIL is traditionally installed in
site-packages/PIL so that everything is available as from PIL import
..., but with a pth file that adds that directory to the path so that
pre-package code still works (there are tons of such code out there).
It looks like the setup.py file achieves this as follows:
extra_path = PIL,
package_dir={: PIL},
packages=[],
where extra_path creates the pth file, and the package_dir stuff makes
sure distutils installs things under PIL and not PIL/PIL. Some quick
Googling indicates that setuptools' support for extra_path is spotty
(non-existent until 2006, limited since then), so maybe this is the
issue?
Could you persuade whoever's ranting about this to jump over to
image-sig and propose a patch that fixes whatever problem Plone is
having but preserves the old behaviour?
Is such a patch possible? If so, could someone do as Fred asks and do so
while resisting the temptation to be rude and further alienate the
maintainer of what is a fantastic package? (yeah, I know, rich coming
from me...)
Wow! Thanks Chris. That sounds like something we can work with. Not to speak
for Hanno, but maybe Hanno could provide such a patch ;-)
cheers,
Chris
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On 2010-04-16, Martin Aspeli optilude+li...@gmail.com wrote: Easy or not doesn't matter: he flat refuses. To play devil's advocate: Why don't we just fork PIL entirely? +1. I think the distribute fork has proven that sometimes this is necessary, and that a fork like this can succeed. Here is a package that *should* just be a no brain dep (possibly with complications due to requiring a compiler, like Zope 2?) but instead has been the bane of everyone's existence for the paste 5+ years (assuming you are using Plone, or some other app that requires PIL). It's fine to say Oh well PILwoTK works, or the PIL that is located *here* work fine. for everyone that understands the issue. However, to solve this problem for real I think a fork is necessary. (Note: I don't know the PIL author personally, nor do I even know he or she's name. I can appreciate the stop bothering me I don't care argument, but if that is really the position of the author then we shouldn't even think twice about forking. Also note: this argument is very similar to PJ Eby's argument re: setuptools, IIRC. In the end, both setuptools and distribute received a lot of 'love' as a result of the fork.) I appreciate that a 1.1.7 came out recently, but before that 1.1.6 lasted three years. I doubt it'd be hard to keep up with a fork. The advantage is that we could package it appropriately, release the new package on PYPI, and avoid all this confusion with names. Count me in. We would need to come up with a new namespace (i.e. not PIL) and adjust our code in Plone and elsewhere to use this new namespace. But that's probably less work than having this debate every few months. +1000. PIL2? visualize (for likeness to distribute)? envision? All are PyPI safe AFAICT. We'd also need someone to *actually do it* ;-) Martin -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Hi Hanno, On 2010-04-10, Hanno Schlichting ha...@hannosch.eu wrote: Hi. I took the time and repackaged PIL 1.1.7 for distribute / setuptools based on Chris work for 1.1.6. There's a fork on bitbucket [1] with my changes. bitbucket is not behaving right now, so I put up a source dist on jarn.com [2]. In order to generate the manifest I used setuptools_hg which is now in setup_requires. I'm not sure that's the best way to do it, so if someone has a better idea, please speak up. After I get some positive feedback, I'll put this into the downloads section on bitbucket and would be happy to see it copied to the usual dist.* places :) w00t. :-) A couple questions: (1) Just curious have you seen any issues with PIL and Zope 2 along these lines: 04:45 wiggy argh, PIL 1.1.7 breaks Zope 06:42 aclark wiggy: how? 06:42 wiggy aclark: it includes an ImageFile module at toplevel 06:42 wiggy aclark: Zope2 has one as well 06:42 aclark ah 06:42 wiggy and if the PIL one is found first things go boom 06:43 aclark can you control the order? 06:43 wiggy nope 06:43 aclark seems to me I've used 1.1.7 w/Zope 2… 06:43 wiggy I suspect it's pretty much random 06:44 aclark interesting 06:44 wiggy try reordeing the paths in bin/instance (2) Why the repackaging? I was under the impression that 1.1.7 alreaded works with setuptools OOB, e.g.: acl...@alex-clarks-macbook-pro:~/Developer/ virtualenv pil-test New python executable in pil-test/bin/python Installing setuptoolsdone. acl...@alex-clarks-macbook-pro:~/Developer/ cd pil-test acl...@alex-clarks-macbook-pro:~/Developer/pil-test/ bin/pip install pil Downloading/unpacking pil Downloading PIL-1.1.7.tar.gz (506Kb): 506Kb downloaded Running setup.py egg_info for package pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py Installing collected packages: pil Running setup.py install for pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py --- using frameworks at /System/Library/Frameworks building '_imaging' extension … PIL 1.1.7 SETUP SUMMARY version 1.1.7 platform darwin 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] --- TKINTER support available --- JPEG support available --- ZLIB (PNG/ZIP) support available --- FREETYPE2 support available *** LITTLECMS support not available To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. changing mode of build/scripts-2.6/pilconvert.py from 644 to 755 changing mode of build/scripts-2.6/pildriver.py from 644 to 755 changing mode of build/scripts-2.6/pilfile.py from 644 to 755 changing mode of build/scripts-2.6/pilfont.py from 644 to 755 changing mode of build/scripts-2.6/pilprint.py from 644 to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilconvert.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pildriver.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfile.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfont.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilprint.py to 755 Successfully installed pil The confusion surrounding PIL almost makes me want to write some sort of über document listing the orginal problem along with all the various hack-arounds. Alex Cheers, Hanno [1] http://bitbucket.org/hannosch/pil-117-distribute/ [2] http://dist.jarn.com/public/PIL-1.1.7-preview.tar.gz -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
