Module dependencies

[Soma]

I splitted this topic from Thumbnails topic. Also splitted and merged few of Soma's replies to these two topics  -apeisa

Now I wanted to install the new renamed, and wanted to deinstall the CropImage first.

Do I need to deinstall all 3 Modules manually? Anyway, after deinstalling the FieldtypeCropImage my PW install is throwing an error and I can't do anything, not even bootstraping. I know, I should have deleted any field using this FieldType first, but wanted to try what happens. Now I think I need to install it through DB again, I'll try.

But regarding installing/deinstalling of such modules using multiple modules, I already wished there would be an more clear and easy way we handle these modules in general. Especially with growing modules that are installed it can get cumbersome to manage. Wouldn't it be cool to just have a Thumbnail module "main" module/installer, which handles only install of the module(s) needed. There we also need some logik for if Fieldtype are still in use in templates, and throw a note to avoid complications like the one I experienced. How could we solve this better (just thinking out loud).

---

I looked at it, and its just an entry in the modules table to install it in DB.

I didn't had to reinstall just drop the Thumbnails folder and delete the CropImage folder... I don't like having three separate folder for one package so I let them in Thumbnails folder.

I don't think there will be much problems once you decide to use as module on a site you most likely will never have to desinstall it, but never say never. Also this can be handled by the deinstall method by the fieldtype himself, check for any template using this fieldtype and throw error. But to improve and simplify the module management in one way wouldn't hurt, and there's already some discussion going concerning module install in the future of PW.

[Nico Knoll]

@Soma: I've got the same problem some days ago. I had to load a backup of my database... If you deinstall one of the modules it has to deinstall the others, too.

[apeisa]

I decided to split this topic from Thumbnails discussion.

This has been discussed at some length before, but since module development is getting more and more active, I think it is good time to think about this again.

How should PW modules relate to each others? Should module be able to say which modules it requires? Currently it works pretty nicely, since modules autoinstall if they are required. But currently it is possible (=too easy) to uninstall and remove required modules all together.

[ryan]

I think that we do want to add module dependencies. It was always the plan, but I left it out just because it originally wasn't really necessary. Now that we're getting a lot of modules, it's time to finish it and add a 'requires' option to the getModuleInfo() where it can specify an array or CSV string of modules it requires. This will be used by the system when installing/uninstalling to check and see if it's okay to install and/or uninstall.

[Oliver]

Besides the information on what modules are required to allow the installation of a certain module, there also should be a version info set. Like "FieldtypeXY > 104" for module FieldtypeXY version 1.04 or above being required.

[Soma]

That's good idea.

I think there will be a need for some manifest file or alike in the future.

Especially when there will be some sort of package installer, and also to avoid complications/conflicts I thought about having some unique key/namespace that would be registered. I think modx has this for their package management.

[Adam Kiss]

Regarding autoinstall dependencies: I never understood why most of the CMS don't give some useful information about the modules. As I see it, you need two information for autoinstalled modules (everyone, in this case): whether user installed this module (yes/no) and how many other installedm modules have this module set as 'i depend on it'.

And when you uninstall module, it can autouninstall all modules that are dependencies AND not user installed AND are not dependencies for other systems. Voilà, done.

It also helps in other things - selecting dependencies to install, yearly mainenance e.g.

[ryan]

Version requirements will definitely be part of our module dependency system.