Confused about composer and implementation

[gmponos]

After the conversation here and by reading the development manual there are some things that I am confused about.

All composer installed library files as well as the autogenerated autoload configuration is checked into git. This ensures that a git checkout (or TGZ download from github) is immediately usable without the need to run composer

A developer and most certainly a PHP developer should know or should learn about composer. This way you will not need to include anything in your vendor folder.

IMHO you should seperate the dependencies into the required ones and development required ones. When you create a zip file to put it in your download page you should then have the required dependancies without the development ones. Drupal does something similar.

This will give you the following benefits:

1. As I said when you create a zip including all the dependancies you can zip only the required ones.

2. You will not commit any dependancy in your repo.

3. You can decouple your code/dependancies. For example IMHO _cs folder should be an independent package like splitbrain/dokuwiki-codestyle which should be included inside the required-dev dependencies. Something like this

4. Composer will solve the dependencies for you. Although there are spots that you are mentioning the required versions in your development manual there are many things left to the imagination. Composer can be a very good "documentation" for the developers that it will always be updated and it will always install the working version.

For instance I haven't seen mentioning the required version of codesniffer (recently 3.0.0-RC2).

Furthermore what if one of the packages creator decides not to respect semver and on the next patch release he believes that it is a good idea to ditch PHP 5.x and go to PHP 7.x. Composer is able to figure this out and will not install this patch version (if the developer is not that crazy and at least he has updated his composer.json file).

5. Although that you are saying that it is immediately usable it is not. A developer has to wonder around a lot to the dokuwiki pages trying to find what dependancies he needs to install like PhpUnit, Codesniffer etc. in order to start developing.

6. IMHO Continues integration will become easier. For instance at the moment you havent' added into travis to check the CodeStyle. I don't know if that was made on purpose or not but by adding codesniffer into your require-dev you could run composer install have your codesniffer and then check the codestyle.

I guess these are just a few of the advantages of using and extending the use of composer. I believe that there are more.

Let me know what you think.

[Klap-in]

(nb: maybe the mailinglist is more common for discussion on this kind of subjects within the DokuWiki project)

A previous thread in the mailinglist was accompanying the PR #1152 containing the current composer setup. The current setup is especially intended for simplify updating of dependencies, without changing the workflow of users/downloaders of DokuWiki source code (so oriented only on the developer who updates the dependencies).
See http://www.freelists.org/post/dokuwiki/Using-composer-to-add-3rd-party-libraries

If I understand it right the alternative setup you propose is targeting at two audiences:

• user: you could just use composer to install the whole DokuWiki software (without development stuff, but including dependencies) and without using git?
• developer: you clone/pull via git, and next you should use composer to obtain all the other dependencies including all its development dependencies (tests, etc, etc)

[splitbrain]

Some more points:

• we are well aware how composer works and how it is supposed to be used and that we do things slightly different
• other than what I stated in my initial mail to the mailing list we still somewhat control what goes into the final release by gitignoring certain library files (https://github.com/splitbrain/dokuwiki/blob/master/.gitignore#L70)
• our php code sniffer setup has never really reached a state were it was actually useful - we could probably remove it unless we want to move all code to a well known supported standard (we're in the process of doing that in PSR 2 Adoption #2358)
• DokuWiki is neither a framework nor a library. Our main target group are non-developers.
• DokuWiki is often running on cheap webspace with no Shell access (often on older PHP releases)
• DokuWiki has over 10 years of history (predating composer, namespaces and many modern PHP features), we deprecate things and modernize over time, but we try not to break things for users horribly

Anyway I'm always open to improve things. So let's see what switching to a more "common" composer workflow would mean:

• 👍 modern PHP users immediately know how it works
• 👎 the tgz download here at github no longer gives you a working copy of DokuWiki unless you can run composer
• 👎 the upgrade plugin could no longer use the tgz from github
• 👎 the one click downloader script can no longer use the tgz from github
• 👎 creating a new tgz gets a tiny bit more complex
• 👎 people using git to keep their wiki up-to-date need to adjust their workflow
• 👍 people could use composer instead to keep their wiki up-to-date

So to me it seems like a lot of things would need to be changed with little benefit (but maybe I'm missing something big here)

Nonetheless I agree that separating dependencies into production and devel would be helpful. We would continue to check in the production dependencies but have an easy way for developers to pull in additional stuff like phpunit (though I usually use the phar anyway). Does that make sense to you?

[MyIgel]

Having a vendor directory in the project is the worst thing for any project and should never be used..
As GitHub allows the upload of binary files for every release this is the perfect opportunity to upload a .tgz and .zip file with all the required libraries and that's the point where the installer / updater should look for and get its files.

[splitbrain]

@MyIgel is that an offer to rewrite all the tools relying on the current setup?

[MyIgel]

I tried but it was a really frustrating experience looking at such a mess of a source code...
& yes, it's all very shitty, i want to set it on fire

[phy25]

Could you please elaborate where the "mess" of source code is?

Please also note that this is a project started back in 2005 when composer didn't ever exist, and

DokuWiki has over 10 years of history (predating composer, namespaces and many modern PHP features), we deprecate things and modernize over time, but we try not to break things for users horribly

Also you may want to read https://www.dokuwiki.org/development

[splitbrain]

I'm closing this. We may revisit our deployment setup from time to time. But for now it is what it is