[33]Library Installer

[pasamio]

Ok, now I'm confused. We will have dependency handling, modelled from Debian in part though perhaps not as thorough in its first incarnation, for all extension types and we're also going to have a library extension to plug into the existing /libraries folder. For Joomla! 1.5, extensions can already put stuff in there if they want to, I know I do because thats why I suggested the things live all the way back in 2005 (time flies when you're having fun). Some of it is in the update stuff and some of it is in this thing. In fact this thread is in part about making the library installer for the extension type 'library'.

Regarding OpenOffice.org, thats a particularly unique case. In a lot of situations, Python versions greater than 2.3 won't work properly with parts of OO.o automation and systems, with a whole heap of other quirks along the line. Having dealt a lot with OO.o, I sympathise with them because its proof that external dependency upgrades horribly break things though I wish they would hurry up and just fix things. Again, internal incompatibilities between the versions of their external dependencies also makes life hard as well, so they're a rather unique case.

I'm not quite sure what you're on about with PEAR, Joomla! is trying to remove PEAR because it isn't compatible with our licence, so we don't particularly care about PEAR however PEAR itself has its own management tools completely separate to us. If an extension wishes to use PEAR and decides they wish to include it with themselves then that is their decision to make. You can install PEAR packages separately and perhaps that should be the guidance from the 3PD about if they use PEAR or not to help you make that decision.

The Windows DLL problem is more a design issue on their part with not figuring on versioning in an environment which heavily needs versioning. Linux and Mac OS X have a similar setup (look in /usr/lib, you'll see tonnes of shared libraries) however things were handled a lot better than Windows. Microsoft has also realised the folly of their ways with their .Net platform (ostensibly stolen from Java which stole things itself) and have versioning properly implemented in their assembly cache.

An additional problem we have is that we can't separate libraries out per instance with Joomla! because we're all in one instance. The current status is going to continue to be unsatisfying because if the two instances of libfoo really do conflict and two things want to load it at the same time then we have no option. This is the same regardless of platform. If an app tries to load two conflicting library versions they're going to have issues. Since the PHP instance is singular per request, if two extensions wish to load conflicting libraries then we're rather limited by PHP with our options.

However, there is an extension I know of that has 8 different plugins and uses two shared libraries between them. Amazing but true and available now for 1.5! Installing libraries is possible in 1.5 for the developer who wants to make the effort, it isn't hard if they want to take that pathway. It may not be obvious to a newbie developer, but its more than possible if they are motivated.

Actually, take out PHP and we get rid of them. MySQL typically doesn't give us headaches with things beyond lacking features in earlier releases, its the quirks and bugs in the various PHP releases that cause issues or issues with stuff like the Zend Optimizer on certain releases of PHP which also break other things or nuke functionality.

@hannes: I'm beginning to think about putting in two more generic installers, one file and one SQL, however I'm yet to flesh them out since I haven't planned the backup framework yet. We would backup the old files, marking the modified ones from the previous release however they would still be replaced with the newer version because there could potentially be a change. Again, patch installs would alleviate this in an interesting way, but its something that requires some more thought because simplistic methods (e.g. never overwrite if modified) are not the best options. An interesting possibility would be to build a patch file and attempt to repatch the modifications. But simpler things first.

[metux]

We will have dependency handling, modelled from Debian in part though perhaps not as thorough in its first incarnation, for all extension types and we're also going to have a library extension to plug into the existing /libraries folder.

Great, that's a BIG step forward
Now it would be good if the installer/package manager can be called outside the webserver
(directly via commandline).

In fact this thread is in part about making the library installer for the extension type 'library'.

Okay, could we provide two kind of "installing" an library: either directly copying in or
including (not copying) from the host system ?

Regarding OpenOffice.org, thats a particularly unique case. In a lot of situations, Python versions greater than 2.3 won't work properly with parts of OO.o automation and systems, with a whole heap of other quirks along the line. Having dealt a lot with OO.o, I sympathise with them because its proof that external dependency upgrades horribly break things though I wish they would hurry up and just fix things.

IMHO, Oo.o is a good example for people being too stupid for properly coping with external
libraries and therefore going even more stupid ways. They even are far too stupid for creating
an sane structure of their own code.
The build process is totally crap, there's nothing to heal.

Again, internal incompatibilities between the versions of their external
dependencies also makes life hard as well, so they're a rather unique case.

Mozilla is on similar path. Not yet that bad, bad already bad enought.

I'm not quite sure what you're on about with PEAR, Joomla! is trying to remove PEAR because it isn't compatible with our licence, so we don't particularly care about PEAR however PEAR itself has its own management tools completely separate to us.

In which way is the license incompatible ?

The Windows DLL problem is more a design issue on their part with not figuring on versioning in an environment which heavily needs versioning.

I'd rather call that absence of design at all. DLLs are nothing more than relocatable objects
with a bit of uninmportant metadata. No dependency information, nor a clear versioning.

Linux and Mac OS X have a similar setup (look in /usr/lib, you'll see tonnes of shared libraries) however things were handled a lot better than Windows.

There's a HUGE difference: ELF dl's carry dependencies and versioning information, and also
named by their versions.

Microsoft has also realised the folly of their ways with their .Net platform (ostensibly stolen from Java which stole things itself) and have versioning properly implemented in their assembly cache.

Didnt cope with that yet. Do they have explicit dependencies ?

An additional problem we have is that we can't separate libraries out per instance with Joomla! because we're all in one instance. The current status is going to continue to be unsatisfying because if the two instances of libfoo really do conflict and two things want to load it at the same time then we have no option. This is the same regardless of platform. If an app tries to load two conflicting library versions they're going to have issues. Since the PHP instance is singular per request, if two extensions wish to load conflicting libraries then we're rather limited by PHP with our options.

The major different between webapps like Joomla and traditional apps is, IMHO, that the
whole thing lives in the same process. You can't just put some component into its own process.
So we have to be *very* careful with shared/duplicated code.

In fact, I don't see the major problem with two conflicting versions of some lib (at whole),
but that parts of the two versions could be mixed up. So, eg. modula A imports v1.0 and
module B v1.1 at the same time, just because of the bundling, not that these lib's interfaces
are incompatible. Even worse: it's already enough that exactly the same lib (same version)
is loaded twice from different places - crashes with duplicate defitions.

Installing libraries is possible in 1.5 for the developer who wants to make the effort, it isn't hard if they want to take that pathway.

Howto ?

MySQL typically doesn't give us headaches with things beyond lacking features in earlier releases,

Might be true if you're not used to code posix-sql.
Let's just take their dubios interpretation of timestamp types ...

@hannes: I'm beginning to think about putting in two more generic installers, one file and one SQL,

What exactly should the SQL-installer be for ?
Why should one load in an standalone schema (outside module, component, library, ...) ?

We would backup the old files, marking the modified ones from the previous release however they would still be replaced with the newer version because there could potentially be a change.

Maybe a bit like Gentoo's etc-update ?

An interesting possibility would be to build a patch file and attempt to repatch the modifications. But simpler things first.

Ugh, now you're going very deep into SCM. I dont think that should happen inside an individual app.
Actually, I even dont think there should be any local changes within an production system - instead
develop separately (and use the tools you like) and only deploy properly packaged extensions.

cu

[Stasys]

please update to TinyMCE 3.2.1

[mgleich]

I have often the problem, that an install task isn't successfull because its runtime is to long. A install of an extension on my local system works, but the install of the same extension on my online system breacks after 30 seconds.

An installer could be breacked the install process into many task. One for upload the extension, one for unpack and so on.

Or is there an other possibility?