Another point that has maybe already been discussed but how do we manage components in the SVN, do we have separate tags and branches for the set of components and each component ? My point is to chose the easiest way to deliver things : if each package must be done manually, it increases the probability of mistakes. The best option is maybe to start with a simple package and then see what happend (some feedback of people). We can keep : - the access to SVN - the pear channel with identified version (like ezc)
Max 2010/11/18 Gaetano Giunta <[email protected]> > James Pic wrote: > >> Hi all, >> >> I'm not qualified to participate actively to the current discussions, >> although i'm reading it all. >> >> However, i'd like to share how it works with python/pinax projects because >> it might inspire you. >> >> On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitt<[email protected]> >> wrote: >> >> Hi Max, >>> >>> On 11/18/2010 09:21 AM, Maxime Thomas wrote: >>> >>>> Actually only the packaging of zeta matters as we want to provide >>>> everything or a part of it. The jQuery UI package download system >>>> seems to be a good start, I guess. Another question comes if we do >>>> like this : will it be possible to make heterogeneous packages with >>>> this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have >>>> a minimum rules to follow ? >>>> >>> Pinax projects use a "requierements.txt" file, for example:: >> >> --extra-index-url=http://dist.pinaxproject.com/dev/ >> >> Django==1.2.1 >> Pinax==0.9a1 >> >> django-debug-toolbar==0.8.3 >> django-staticfiles==0.2.0 >> -e git+ssh://[email protected]:jpic/sorl-thumbnail.git#egg=sorl-thumbnail >> >> That file is tracked by the VCS in each project. To deploy a new >> environment >> for my project, all i have to do is:: >> >> # pip is like pear, for python >> pip install -r requirements.txt >> >> That allows: >> >> - each project to have different component dependencies >> - with specific versions >> - deployment is piece of cake >> >> I don't think it's possible with official pear, anyway: if we decide that >> it's the way to go then we'll find a way. >> >> shame on pear! > > otoh: would we have such info available for existing components or would it > be so hard to extract it in a precise and useful way that it would not be > done anyway (I mean apart from the obvious compatibility that we get from > the complete bundles)? > > Regards >> >> James >> >> >
