search

akeeba / fof

Rapid Application Development framework for Joomla!™ 3 and 4
0 stars 0 forks source link

Adding FOF to Packagist #355

Closed speedy111 closed 10 years ago

speedy111 commented 10 years ago

How about adding FOF (and Akeeba Strapper) to https://packagist.org? Developers can then easier use composer and FOF for their extensions. And a bonus is that more developers might discover FOF.

nikosdion commented 10 years ago

FOF depends on the Joomla! CMS which is not on packagist. To the best of my knowledge, that would make it pointless. Maybe we can do that with Awf that's actually (also) a standalone framework, when it's released of course.

speedy111 commented 10 years ago

FOF depends on the Joomla! CMS which is not on packagist.

Yes that's true, but it's not pointless. Our extensions depend on a certain FOF version. I also have my own framework which also has to be compatible with the extension and FOF. By using composer this can be handled nicely and we can then build older versions of our extensions without having to look for all the correct versions of the dependencies.

Btw Joomla! CMS is on packagist apparently: https://packagist.org/packages/joomla-libraries/cms

I've only just started investigating this. The only disadvantage I've encountered so far is that you can not ignore files, which are required for the zip package (e.g. .xml installation file), in the .gitignore anymore. Else you can't include them when building the extension.

nikosdion commented 10 years ago

I do not understand how Composer would help you with that. Your extension has to work with whichever FOF version is installed on the site. If it's earlier than the latest official release you have to upgrade it. If not, don't touch it. That's the guidelines I'm giving you. You can't have two versions of FOF running side by side unless you fork FOF and rename all of its classes.

If you are worried about running the latest stable FOF build you don't need Composer. The master branch always contains the latest official build, the development branch the latest in-progress version and the tags have all past versions. Moreover FOF is really strong on B/C. If something will break you guys know it months in advance. Apparently all you need is switch to development branch for testing and master for release.

speedy111 commented 10 years ago

I do not understand how Composer would help you with that. Your extension has to work with whichever FOF version is installed on the site. If it's earlier than the latest official release you have to upgrade it. If not, don't touch it. That's the guidelines I'm giving you. You can't have two versions of FOF running side by side unless you fork FOF and rename all of its classes.

We have now FOF, F0F (2.3) and soon there will be FOF 3.0. These versions are not compatible (first 'migration' was bad luck, second migration is just major maintenance). For example, if I'd like to build an older release of my extension which requires FOF in stead of F0F then I'll have the issue I described above. If you then also have another library (which I have) then it gets more complicated. When I'll use composer I can just build it and it should work. I've not yet experience with composer, but I think this simplifies the build process. I however only don't like that I can't ignore required files anymore with .gitignore.

If you are worried about running the latest stable FOF build you don't need Composer. The master branch always contains the latest official build, the development branch the latest in-progress version and the tags have all past versions. Moreover FOF is really strong on B/C. If something will break you guys know it months in advance. Apparently all you need is switch to development branch for testing and master for release.

Yes I understand. Also regarding the strong B/C, but there will be backward incompatibilities which every descent software has sooner or later.

nikosdion commented 10 years ago

FOF up to and including 2.2 is under libraries/fof, does not use namespaces and its classes are named FOFSomething

FOF 2.3 is under libraries/f0f, does not use namespaces and its classes are named F0FSomething

FOF 3.x will be under libraries/f0f, inside a different directory per minor version (no b/c breaks), will use namespaces and the namespaced class name will not collide with previous versions.

The point is that every time there is a b/c break we did have a mitigation way, we do have a mitigation way and we'll have an even damn better mitigation way.

Composer DOES NOT provide a way to mitigate b/c. Composer is DEPENDENCY MANAGEMENT. More specifically, it's the kind of dependency management that is suited for bespoke applications which use a single copy of a single version of each library (a.k.a. "dependency") at a time. When you have a single system which runs different applications at the same time inside the same execution environment using Composer AMPLIFIES the problem of backwards compatibility as your one and only option is to have a SINGLE version of each library in a centrally accessible location.

speedy111 commented 10 years ago

Composer is DEPENDENCY MANAGEMENT.

I understand. The code of our extensions is different for these different FOF versions. E.g. FOF vs F0F classes. I think our misunderstanding is that I'm referring to the build process. Let's say I've com_foo which requires FOF 2.0.0. In stead of having to look through the FOF branch searching for the 2.0.0 tag (current approach), it can be retrieved automatically with Composer. Also the dependency is hardcoded and tested, so I'm sure which version belongs to com_foo.

Then only ship 1 version of FOF, just like what I would do without Composer. So the zip package can be exactly the same as when I'd use the current build process (maybe I reorganize it, but it's not required). I don't have in mind to ship multiple FOF versions with one extension. The same story holds for my framework version.

-edit- With this new workflow various files of the .gitignore should be included, e.g. com_foo.xml. After every build these files are altered and should be committed again. This is something I really don't like. This could be prevented by building all the packages which are downloaded by Composer. So first downloading the files via Composer and then building FOF, my framework and then building com_foo. In order to build these files (under /vendor) they first have to be symlinked and have to include Akeeba Buildfiles. Not so KISS after all... I might just pass this idea.