Re: bundles

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.

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. 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.

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? 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. 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.

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).

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. Greg