Re: bundles

On Wed, 2004-09-15 at 00:10, Greg Beaver wrote: > Lukas Smith wrote: > > Stig S. Bakken wrote: > > > >> Hi Greg, > >> > >> If I understand your proposal correctly, you define bundles as a list of > >> sub-packages that have a "contained by" relationship with the > >> "bundle" package. But you could regard a bundles simply as an empty > >> package with > >> regular dependencies. You would lose the "contained by" relationship, > > This is not accurate. You might want to browse the thread again, I've > spoken of two different kinds of bundles. One is external to packages > (the empty package idea), and the other is a contains relationship. > Neither is subpackages. Sorry for making that assumption, read up on pear-core cvs mails now, glad to hear sub-packages are no longer a topic :) > >> but > >> the overall complexity would be much lower. I know we talked about > >> sub-packages last year, but I'm starting to get cold feet wrt. all the > >> extra system complexity (PEAR is complex enough as is). > > bluntly: I'm a big fan of enough complexity to get the job done. No > more, and more to the point, no less. In *many* areas, the installer > errs deeply on the side of not getting the job done, sacrificing design > for "simplicity" that has actually made maintaining and using the code > 10 times more difficult. I agree with you on this: enough complexity to get the job done. The installed could have been a lot cleaner and St. Peter will probably give me some heat for PEAR_Common when that time comes. But that was the tradeoff I had to make to get PEAR up and running, fully aware that the installer needed a rewrite down the road. > This idea is not subpackages, it bears no resemblance to our discussion > of last year, it is simply a shortcut. The web installer would > literally not need it, but users could browse the bundles and decide > what they want. More on the complexity issue below. > > >> My main concern is that we are getting quite a few dimensions to consider > >> for dependencies: > >> > >> * package name > >> * release platform (with all the cpu vs. OS vs. vendor fun) > >> * release version > >> * release provides (class/interface/function) > >> > >> Handling four-dimensional dependencies is for brave coders, but it's > >> well-defined enough. Adding sub-packages to this muddies things up, > >> because a package is no longer a package, and a release is no longer a > >> release. What _is_ the difference between DB_mysql and DB#mysql? > > This is semantics - in reality, names would be chosen that are easier to > differentiate, just as they are with package names now. Also, I'm *not* > talking about adding subpackages. These "contains" bundles would define > groups of packages that *could* be used for grouping subpackages, but > also likely for configuration choices. > > I also don't understand why handling 4-dimensional dependencies is for > brave coders - unless you feel that every PECL author is a brave coder, > which they would probably appreciate :). These dependencies are not > creations out of thin air, they are real. The fact that they are not > explicit in the package file has caused me more than one headache when I > think "oh cool, this does what I need," and so I download and try to use > it, but it fails because I don't have so-and-so extension, but I can't > for the life of me figure out what I don't have. > > Figuring out dependencies is usually a one-time event for developers, > but for users, it is a life-saver. It's about common good. A little > (and it is slight) extra contemplation by developers as to what their > code needs, and the users can rely upon the code even more confidently. The brave coder in consideration is the one who needs to write and maintain/understand the code to _resolve_ four-dimensional dependencies, especially when one of the dimensions (platform) is non-linear. But this was really a comment about adding sub-packages. > >> I think sub-packages would make something that is already complex enough > >> to understand and keep track of, more complex. Simple is good. :) > >> > >> So, by dropping the "contained by" relationship and the concept of > >> sub-packages, we end up with the possibility of having a package that > >> contains multiple packages, all in the same package.xml format. > >> > >> You can still do the "bundling" by embedding the actual package files > >> Example filelist from a hypothetical DB-2.1 package (this one contains > >> some binary packages just for example): > >> > >> <filelist> > >> <file role="pkg" name="DB_mysql-2.1.0.tgz"/> > >> <!-- ... and maybe something like this: --> > >> <file role="pkg" > >> name="mysql-2.1.0-linux_2.4_i386_glibc2.3.tgz" > >> platform="linux-*-i386-glibc2.3"/> > >> <file role="pkg" name="mysql-2.1.0-freebsd_4.10_i386.tgz" > >> platform="freebsd-4.10-i386"/> > >> </filelist> > >> > >> Simple, straightforward to understand, easy to implement :) > > This requires the other packages to be a part of the tarball, no? Just an idea, makes "bundles" becomes more like the name suggest. But having packages with only dependencies works too. > Upgrading becomes hard to implement, if not impossible, and each package > has its own copy of anything it uses. This is one way of doing things, > but it is the way of doing things *before* PEAR existed, one that makes > fixing bugs and maintaining separate releases a living hell. I should have elaborated more. The purpose of including actual packages is _only_ convenience / bootstrapping. For example, PHP releases could contain a single bundle (PFC or whatever), and the install would still do the same thing as today. The difference is that there is only _one_ package(bundle) to deal with. Not including the packages (but having only a list of dependencies) would be cleaner. Both would work; embedding the required packages is very useful for magazine CD-ROMs etc. Just throwing the idea out. FWIW, CPAN has had bundles containing other packages for a long time, and seem to be moving more towards that approach. > The ONLY reason I've been devoting time to the installer is to remove > that living hell from the future. > > I am not interested at all in easy to implement. I am interested in > three things: > > 1) easy to use > 2) easy to maintain > 3) easy to extend > > not necessarily in that order. They are wholesale opposites of "easy to > implement" in more than half the specific projects I have coded, as this > usually implies the least thought-out design. I have a feeling you have been over-exposed to some old pear-core code committed by yours truly :) > > Yeah I see that complexity is a danger and I agree we should be taking a > > KISS approach even if that is slightly less sophisticated on some minor > > level. > > "Make it as simple as possible, and no simpler" is exactly what I'm > looking for. Some of the time only one side of that statement is executed. > > > Anyways to me subpackages have always simply been packages with a dep on > > a given package that will also get uninstalled along with the parent > > package if the parent is uninstalled (or the parent can only be > > uninstalled if all subpackages have been uninstalled or something along > > those lines). Thats all. > > Precisely - subpackages exist today, independent of the installer. I'm > not talking about adding subpackages (DB_DataObject_FormBuilder could be > considered a subpackage of both DB_DataObject and HTML_QuickForm, no? > HTML_QuickForm_Controller is a pure subpackage of HTML_QuickForm). You could get away with that, but the definition it too vague and certainly not deterministic. But it doesn't matter... > > Now as to bundling I do see Greg's point that managing all the > > permutations of sensible "bundle" with empty packages can become quite > > daunting and lead to alot of empty packages quite quickly. For example > > LiveUser would be a package where you can optionally use Crypt_RC4 in > > combination with several different backends. So it would be cool to be > > able to say I want to install LiveUser with all security options and MDB > > backends and get all relevant optional dependencies installed and at the > > same time only get the MDB backend drivers (and not the XML, MDB2, DB, > > PEAR_Auth etc. backends). > > > > If I got Greg correctly than this is what he was aiming for with bundles > > and I dont think this is something we can sensibly provide using empty > > packages which would need to be created for every bundle we might want > > to provide. > > Precisely. One part of the proposal that I threw in as an aside "and > you can specify a bundle in a dependency" has been making me uneasy as I > have started to work on implementing this. I think (today) it may add > in too much uncertainty. What is indeed better is to eliminate this > option. Instead of: > > <dependencies> > <package name="DB" bundle="mysql" recommended="1.7.0"/> > </dependencies> > > It would be more robust to assume the default bundle is required unless > explicitly not requested > > <dependencies> > <package name="DB" nobundle="yes" recommended="1.7.0"/> > <package name="DB_mysql" recommended="whateverversion"/> > </dependencies> > > As for the complexity, users will not even need to know the bundles to > continue working normally, so the question of DB_mysql versus DB#mysql > is moot - anyone who doesn't understand it quite literally doesn't need > it. These will be primarily for developers of complex applications to > allow them to utilize the installer to customize the application. > > $ pear install DB > > will continue to work just as it always has, and only those who wish to > do some streamlining will even need to know about bundles. > > As for bug reports, this will be the only complexity that would be > added, just because large packages will become a myriad of separate > packages. A bug for DB may be in the mysql driver. A quick look by the > DB maintainers would allow them to instantly transfer this bug over to > the DB_mysql package where it belonged in the first place, just as bugs > are easily transferred from the web site or bug system to an actual > package today. I think the way you're using the term "bundle" in your examples is confusing. The bundle is the superset, not the fragment. So if "pear install DB" will work as it always has, how does your bundling proposal differ from having a package with packages and dependencies? - Stig (going to sleep now)