[kamaelia-list] First monthly, or so, interim release made
Hi, First monthly interim release has been made, and can be found here: * http://www.kamaelia.org/release/MonthlyReleases/Kamaelia-0.9.6.0.tar.gz This is a snapshot essentially of here: * http://code.google.com/p/kamaelia/source/browse/trunk/Code/Python/ With minimal packaging on top. Unlike a full release, this has the following limitation: * Cannot be installed using easy_install But that also means: * Can be installed using plain old distutils and doesn't require easy_install or setuptools, etc. If you don't want to track /trunk from subversion, but do want a recent release, this is the best option until the next full release. Regards, Michael. -- http://yeoldeclue.com/blog http://twitter.com/kamaelian http://www.kamaelia.org/Home --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: Autoloading Components based on Imports
Matt Hammond a écrit : >> So some questions arise: >>1. Good idea or not? >>2. Really? Could be viewed as bad mojo & messing about one step too >> far. >>3. If OK, should it be static? ie the list of what gets imported and >>handles what dealt with by a table lookup in Kamaelia/__init__.py ? >>4. Or should it go "OK, I was imported here, I'll rummage around in all >> my >>subdirectories, in this overall order" >>5. Do 3, then 4, if the name wasn't found in 3. >>6. The other way round ? >>7. Do we allow extra search paths for the case of 4 ? (think sys.path >> for >>modules) >>8. How about allowing extra lookup tables to be added in the case of 3? >>9. lots more possibilities. >> > > I can see it would be much less verbose and that is a *good* thing! If > nothing else, from writing examples in documentation, where brevity is > highly desireable, adding all those import statements can be tedious and > ugly. > True and yet I welcome that verbosity. I did a bit of Ruby and the first thing that annoyed me was that there was lots of magic going on in module finding and since the language allows you to change things rather dramatically at so many levels I ended up being lost and frustrated quickly. I appreciate the fact that the current verbosity means I know where things are coming from and never worry about name clashing. - Sylvain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Re: Autoloading Components based on Imports
> So some questions arise: >1. Good idea or not? >2. Really? Could be viewed as bad mojo & messing about one step too > far. >3. If OK, should it be static? ie the list of what gets imported and >handles what dealt with by a table lookup in Kamaelia/__init__.py ? >4. Or should it go "OK, I was imported here, I'll rummage around in all > my >subdirectories, in this overall order" >5. Do 3, then 4, if the name wasn't found in 3. >6. The other way round ? >7. Do we allow extra search paths for the case of 4 ? (think sys.path > for >modules) >8. How about allowing extra lookup tables to be added in the case of 3? >9. lots more possibilities. I can see it would be much less verbose and that is a *good* thing! If nothing else, from writing examples in documentation, where brevity is highly desireable, adding all those import statements can be tedious and ugly. I would also worry about the situation where two or more components share the same (leaf) name. Eg: Kamaelia.Chassis.Pipeline Kamaelia.Experimental.Chassis.Pipeline There are also other components which, although they do not clash now, look likely to later, eg: Kamaelia.Audio.Codec.PyMedia.Decoder.Decoder I suppose I'm asking, will someone's code break X months/years later when more components are added to teh repository with the same name? This concern therefore makes me worry this could be a short term gain which causes future difficulties. But maybe this is still a good idea and the solution is to develop a stricter component naming policy? (and retrospectively rename existing components to fit it) Another perspective: If one of the problems this is trying to solve is disagreement over where a component should be located in the hierarchy; this could be solved by symlinking - ie. let the component be in both places in the hierarchy where it is believed to make sense. However, I guess this could end up being highly confusing! I can see it would make sense if you consider the hierarchy as a hierarchical classification scheme, rather than a packaging/encapulsation thing - eg. more like categories on Ebay than packages in java. -- | Matt Hammond | | [anything you like unless it bounces] 'at' matthammond 'dot' org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
[kamaelia-list] Version numbering changed on /trunk
Hi, Just so that everyone's aware, I've changed the version of Kamaelia on /trunk, yesterday and changed the numbering scheme on /trunk to as follows: * 0.9.6.0 Which if we break that down as: * Y.Y.M.R Maps to * Year - 20YY hence 09 * Month - M - hence 6 * Release number from that point - R - hence 0 (not released yet) Regarding release & version numbering it has 2 main purposes from a person's perspective IMO: * Is it mature/stable ? * Is the version I have the most recent one ? At least that's what I look for :-) The reason for 0.9 is because that means next year (~6 months from now) we hit version 1.0 - which feels about right from a development perspective - since there's a number of emerging patterns for component development & chassis development. The reason for adding the release number is in case of 2 reasons: * We move to a faster release cycle * In case we move to a situation where we have stable & testing releases. We'd then end up with the possibility of a bugfix against a stable release made some time back. By bumping the release number for that rather than the YY.M part it'd make it clear it's just a bugfix - without any particular hassle. I don't think any of this is controversial, but I am interested in hearing if this numbering causes any problems for tools, and whether something like XX.Y.M-R eg 0.9.6-0 would be better. (However, not using that latter form enables distributions to use that for versions of packages). Note, this also always give us a way of talking about specific general versions of /trunk - rather than "in revision 6179", you can can say "well in 0.9.6.0 ..." which instantly gives a lot more information. Again, the .0 at the end also means we could start building regular tar balls (say near the end of the month) to make available as the last snapshot for that month. These wouldn't be declared stable releases, etc, but would be nice to have. Any thoughts on this welcome, otherwise if I don't hear any comments, I'll assume the new numbering scheme is considered a good idea :-) Regards, Michael. -- http://yeoldeclue.com/blog http://twitter.com/kamaelian http://www.kamaelia.org/Home --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~--~~~~--~~--~--~---
