[Zope3-Users] Zope 3 Foliage Sprint
Hi everyone, it has been over a year, since we had a conference-independent fully Zope 3 focused sprint. And I think it is time to have one! :-) Thanks to JSA Tech, there will be a sprint between September 24-28, 2007 right in the center of historical Concord, Massachusetts. We have reserved a big room where we can easily fit 35 people. For details, go to the link below: http://wiki.zope.org/zope3/FoliageSprint Now that some fairly large Zope 3 projects are in production, this will be a great opportunity to share our experiences, to learn from each other and discuss new directions that we would like to go. Upon request, I will also give some of my Zope 3 training sessions during the sprint. So I envision the sprint to be interesting for any level of Zope 3 developer, from the beginner to the expert. So sign up now! Just add yourself to the list of participants in the Wiki or send me an E-mail, if you can't. Regards, Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Eggs, workingenv.py, and 'classic' instance homes
Jeff Shell wrote: But now I'd like to be able to install that into classic zope 3.3 instance homes, trying to be as unobtrusive as possible. I don't know anything about workingenv, but I would just use Subversion externals. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Eggs, workingenv.py, and 'classic' instance homes
My office's migration to eggs and the like is going slowly (too much other work to do). However, I'm trying to do new work in the 'right' way and use eggs and buildouts for making small reusable packages. I did such a package yesterday and it works like a champ on its own: buildout can get everything it needs to run the tests, the tests have 100% coverage (yay!), etc. But now I'd like to be able to install that into classic zope 3.3 instance homes, trying to be as unobtrusive as possible. I tried using 'workingenv.py' and it looked like a decent solution...for a moment. However, when I try to install my component it then starts trying to install the dependencies. Even when I specify '--no-deps' to easy_install. Since the Zope 3.3 installation satisfies most of my component's dependencies, I don't want it fetching everything else. But I do want it to get those pieces for testing, etc. I've worried about this issue for a while -- how to get setuptools to ignore dependencies that are satisfied by some big installation like Zope 3.3. In my setup.py, should I move all of my 'install_requires' bits that are satisfied by a regular Zope installation into an 'extras_require'? Thanks, Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Eggs, workingenv.py, and 'classic' instance homes
Jeff Shell wrote: My office's migration to eggs and the like is going slowly (too much other work to do). However, I'm trying to do new work in the 'right' way and use eggs and buildouts for making small reusable packages. I did such a package yesterday and it works like a champ on its own: buildout can get everything it needs to run the tests, the tests have 100% coverage (yay!), etc. But now I'd like to be able to install that into classic zope 3.3 instance homes, trying to be as unobtrusive as possible. How have you installed other packages before? I suspect by just dumping their source in INSTANCE/lib/python. Any reason not to continue to do that? I tried using 'workingenv.py' and it looked like a decent solution...for a moment. However, when I try to install my component it then starts trying to install the dependencies. Even when I specify '--no-deps' to easy_install. Sounds like a bug in easy_install or workingenv then... Since the Zope 3.3 installation satisfies most of my component's dependencies, I don't want it fetching everything else. But I do want it to get those pieces for testing, etc. I've worried about this issue for a while -- how to get setuptools to ignore dependencies that are satisfied by some big installation like Zope 3.3. In my setup.py, should I move all of my 'install_requires' bits that are satisfied by a regular Zope installation into an 'extras_require'? That seems backward. If you want to install an package into a classic environment, it doesn't seem that surprising you'll also have to do it the classic way... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Eggs, workingenv.py, and 'classic' instance homes
We don't use subversion. I wish we did... Or something like it. But my fallback plan is something similar - use our rockout scripts to automate checkouts into auto-built namespace packages. Its how we get things like zc.resourcelibrary now. I'd like to move to using proper releases, but it's been an uphill battle just to get this far. On Aug 16, 2007, at 11:29 AM, Benji York [EMAIL PROTECTED] wrote: Jeff Shell wrote: But now I'd like to be able to install that into classic zope 3.3 instance homes, trying to be as unobtrusive as possible. I don't know anything about workingenv, but I would just use Subversion externals. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Eggs, workingenv.py, and 'classic' instance homes
Jeff Shell wrote: But now I'd like to be able to install that into classic zope 3.3 instance homes, trying to be as unobtrusive as possible. How have you installed other packages before? I suspect by just dumping their source in INSTANCE/lib/python. Any reason not to continue to do that? Because I feel like we're falling further and further behind, or at least trapped in our own little world. But yes, this is how we did it. I ended up writing most of rocketbuild/rockout (our Rake-ish tool) because of this. There are a lot of external tools out there that we still don't use because we don't have the time to deal with the headache (made minor by `rockout`, but still present) of dumping sources into lib/python. For internal stuff, it's not so bad. The longer we avoid whatever is going on with setuptools and buildout, the harder it will be to migrate. It's hard enough already. I tried using 'workingenv.py' and it looked like a decent solution...for a moment. However, when I try to install my component it then starts trying to install the dependencies. Even when I specify '--no-deps' to easy_install. Sounds like a bug in easy_install or workingenv then... Since the Zope 3.3 installation satisfies most of my component's dependencies, I don't want it fetching everything else. But I do want it to get those pieces for testing, etc. I've worried about this issue for a while -- how to get setuptools to ignore dependencies that are satisfied by some big installation like Zope 3.3. In my setup.py, should I move all of my 'install_requires' bits that are satisfied by a regular Zope installation into an 'extras_require'? That seems backward. If you want to install an package into a classic environment, it doesn't seem that surprising you'll also have to do it the classic way... It doesn't seem entirely backward. I mean, it does. But at the same time... I just don't know how it's all supposed to work. But if we keep doing things in the 'classic' way without trying to step forward, then I fear we'll stay this way forever because it's already scary enough peeking over the hill at how buildout and all of that stuff works and how different it is from how we've done things. I don't want the gulf to get bigger, because I think that with our plans for growth and for a more distributed deployment server setup, 'buildout' will help tremendously. I'm just trying for baby steps right now, because it feels like we've still got a long way to go to get to anything better. I saw mention of 'workingenv' in your book, so I assumed it was or is possible to easily have instance homes with locally managed eggs. Shouldn't it be? I assume so, so I guess I may have just run into yet another setuptools bug that I get to hack around. Yay. -- Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
