Composer installation

[teppokoivula]

Hey Robin!

I've got quite a few sites using this module (it's brilliant!) and I'd really like to move on to having all modules installed via Composer. Would you be open to adding MinimalFieldset to packagist.org? :)

You're probably aware of the workflow, but just in case:

1. Add a composer.json file, here's a minimal example:

{
    "name": "toutouwai/minimal-fieldset",
    "type": "pw-module",
    "require": {
        "wireframe-framework/processwire-composer-installer": "^1.0.0"
    }
}

(Just a quick note: Packagist complains if the author name is not all lowercase, and the installer plugin in turn expects to see dash as a word separator in the package name so that the directory for minimal-fieldset becomes MinimalFieldset.)

2. Add the package to packagist.org: https://packagist.org/packages/submit

You may also want to set up git hooks between Packagist and GitHub (Packagist has guide for this if you haven't done it before) so that package information (primarily new versions/tags) get automatically updated there :)

3. Add tag / tags to the repository. This is not strictly necessary, but will make it much easier for others to use/install/update the package.

Thanks for considering this :)

[Toutouwai]

Hi Teppo,

I'm not totally closed to your request but it's something I'd like to think about and if I do go ahead it's something I'll save for some rainy day.

My concerns are about the additional work for me (and it's the kind of maintenance work that is least appealing to me), and weighing that against the size of the audience who are going to benefit from changing my standard workflow.

I think it's great that some devs are motivated enough to add tags, releases, changelogs, etc to their repos but frankly I can't be bothered with that. I feel like my contribution is the code itself, which I primarily write for my own sake and then if it's no extra work for me I'm happy to share it with the PW community in case someone else finds it useful.

I have authored 107 PW modules to date, a portion of which are not in the PW modules directory and another portion that are in private repos. Now if I add webhooks for Packagist (which I understand have to be configured per repo) and tag every version-changing commit then I have to decide if I'm just going to do this on some subset of repos that I've received requests about (which means me having to remember which repos those are) or if I'm going to do this across the board for all my PW modules.

Then there's the question of audience. I see from your proposed composer.json that this creates a dependency on your wireframe-framework module, which isn't really a problem but if I understand right this reduces the audience from "PW users who want to install one of my modules via Composer", which is already a very small audience I think, to "PW users who want to install one of my modules via Composer and who are simultaneously using wireframe-framework". Could this in fact be an audience of 1 person?

So I'm wondering if there is some other way for you to solve this need. Like, could you fork the repos, add your composer.json and then somehow automate updates from the source repo, adding any tags that you can be bothered to add? Or what if I added you as a collaborator to certain repos and then you can do the extra work needed?

I don't mean to sound negative and I appreciate your interest in my modules, I'm just finding it hard to muster the enthusiasm to take this on when it doesn't fit in with my normal workflow.

[teppokoivula]

Hey Robin,

Thanks for your thoughtful response — appreciate that. And, of course, appreciate all your may contributions as well :)

I get that this may not be something you're interested in, especially if you're not using Composer for this purpose yourself. I'd say that this type of workflow is still relatively rare in the ProcessWire ecosystem. Personally I hope it'll gain more ground, and having decent support for module installs is a part of that. Very few third party module can be installed via Composer "the proper way" (without referring to specific GitHub repositories etc.) which obviously makes it less useful/interesting :)

I'll just address some points from your message, and then let you decide the best route:

Now if I add webhooks for Packagist (which I understand have to be configured per repo) and tag every version-changing commit then I have to decide if I'm just going to do this on some subset of repos that I've received requests about (which means me having to remember which repos those are) or if I'm going to do this across the board for all my PW modules.

That is a good point. That other stuff you've mentioned (changelogs, releases, etc.) are not necessary, but this would indeed mean adding a per-repository webhook and adding tags for releases. For me this is pretty much automatic, it feels weird not to do it (and it helps if I want to step back to a specific version to see if / what has changed and why), but I get that if it's not a part of your workflow then it'll just mean some extra work.

creates a dependency on your wireframe-framework module [...] "PW users who want to install one of my modules via Composer and who are simultaneously using wireframe-framework".

This is actually not quite true: processwire-composer-installer is a Composer installer plugin that, by default, installs modules into site/modules/ModuleName/ instead of the Composer-native vendor/author/package/ directory. In other words this should be added so that ProcessWire users to install modules in the first place. The plugin also allows the parent project to modify the default installation path for modules, which is a need that sometimes comes up with, say, cloud based setups.

(For the record there is a "general purpose" CMS plugin/module installer project too, but I haven't yet had time to test it out.)

Technically this dependency is not required as long as the parent project (or any of the modules that are installed before this one) have it and the type is "pw-module", but that's a different story and not really a behaviour that can be relied upon.

On a loosely related note: the one and only reason processwire-composer-installer is under the wireframe-framework project is that I didn't want to make it seem like "my personal project" by slapping my own name on it :)

So I'm wondering if there is some other way for you to solve this need. Like, could you fork the repos, add your composer.json and then somehow automate updates from the source repo, adding any tags that you can be bothered to add?

This has roughly been workflow for repositories that are no longer maintained or not publicly available: create a (private) fork, add composer.json and tags, push it to (private) Packagist. Packagist.org doesn't allow forks so this won't "benefit the general public", but we've got a separate private Packagist setup that makes it work for us in-house.

Automation is something I've not done, though it of course could be done, at the very least by polling GitHub API etc. So far I've not felt a need for this: the volume is pretty low and it's actually nice to be able to review updates manually at this stage before deploying to multiple sites :)

Or what if I added you as a collaborator to certain repos and then you can do the extra work needed?

I'd be very happy to do this if it's OK for you!

I don't mean to sound negative and I appreciate your interest in my modules, I'm just finding it hard to muster the enthusiasm to take this on when it doesn't fit in with my normal workflow.

I definitely get this, no pressure :)

[Toutouwai]

Hi Teppo,

I've added the module to Packagist.

Cheers, Robin.

[teppokoivula]

Thanks, Robin!