Spinning off plugins as separate projects

[gohanman]

I think it would make a lot of sense for plugins to exist as separate, individual projects.

I wrote a composer plugin so that plugins can be managed using all the existing PHP package infrastructure. I also wrote a trivial example of an existing one.

There's probably a very minor performance advantage to not having unused plugins present in your install since those directories have to be scanned during class discovery. But the bigger advantage is to provide a more sensible path for basic customizations. Forking the main project inevitably means you need to manage the entire codebase's updates.

[gohanman]

Running list of repos:

• Lane Plugins
  • AccessProgram
  • AllItemProdUserSearch
  • AllItemSearch
  • AlwaysFoodstampTotal
  • AnnualMeeting
  • BitCoin
  • CashDrop
  • CoopCred
  • ECheckPlugin
  • InactiveMemLookup
  • ItemSearchWefcToronto
  • MemberCard
  • MiscLogging
  • NeedBasedDiscount
  • Paycards
  • PhoneLookup
  • PriceCheck
  • PromptForTare
  • QuickKeys
  • QuickMenus
  • ReceiptOff
  • StripeDotCom
  • TaxExemptPlugin
  • VirtualCoupon
  • WedgeStaffCharge
  • WfcHtmlReceipt
  • WfcMadCoupon
  • WicPlugin

My goal is to have all of the lane side plugins separated out by version 2.2. Some of these are plugins I didn't write and/or I don't use. I'd be happy to transfer ownership of repos to someone else in cases where that makes sense.

---

A couple other advantages I've noticed now that I've repackaged a handful of these:

Testing is way, WAY easier. All the plugins have a similar format right now with noauto/bootstrap.php providing a fake versions of CORE API classes. This lets me mock everything outside of the plugin itself and know exactly what every API method call will return.

Versioning should be much easier too. Because the repos are small and testable I can push changes quickly with more confidence. But at the same time with small repos changes should occur less frequently and fit much more cleanly into categories like "bug fix" or "new feature".

It should be possible for plugins to depend on other plugins using composer's normal require and have dependencies automatically resolved. There are few situations where this matters right now but could be more useful as the number of plugins grows (or a long-term argument for further modularizing non-plugin code into discrete, independent repos).

Docs: https://github.com/CORE-POS/IS4C/wiki/Plugins#packaging-a-plugin-with-composer

[gohanman]

To expand on the thinking here, the ultimate goal here is to simplify updates so that developers and end users can stay up to date with features and fixes more easily. There are a few different, overlapping objectives to get there:

Drawing a bright line between plugins and other code

The way mainstream projects like Wordpress, Drupal, etc deal with updates is by overwriting everything except for plugins. If you're making changes outside of the dedicated plugin structure updates make no effort to preserve those changes. I don't think this approach will work for every CORE use case but if it does work for some CORE use cases this is very much the simplest update mechanism.

Normalize the use of composer

Managing the installation of multiple plugin packages requires good tooling and infrastructure or it'll just create lots of extra work. Composer is widely used by the larger PHP community and fits this need extremely well. With proper tooling I think being able to install, uninstall, upgrade, and downgrade a number of small packages will be significantly easier than trying to manage just one gigantic software package.

Break the rest of CORE into smaller packages

This is the doozy and establishing the use of a package manager is an essential prerequisite, but this would make almost everything easier. Smaller packages have tighter change logs. They're easier to test and verify for stability. Fixes can be turned around faster. End users can try new features without much concern for breakage since downgrading back to the previous version of a package is always available if needed. In some cases it would be possible to replace CORE components with widely used 3rd party packages and that would have even greater stability gains. Forking smaller component packages if needed will have proportionally fewer merge conflicts to deal with. And composer makes it really easy to substitute your own fork for a given package. Downstream installs should never be in a position where (for example) they can't install a new backend report because they need a change to receipt handling that hasn't been incorporated upstream yet. To deal with a merge in that situation now you more or less need to be familiar with the entire code base and that's a serious barrier to entry.

---

This has come up in the past with the notion of shifting Lane and Office into separate projects and I realize what I'm describing here is a much more extreme refactor. The difference in my mind between then and now is that the larger PHP community has created tools that make it straightforward to have a single logical project that makes use of many github repos. This is very much long term planning but I think it's ultimately in line with the project goals to make CORE increasingly modular and customizable without said customizations leaving end users in a stop where upgrading other modules is difficult.

[gohanman]

Coincidentally, I ran across plugins.roundcube.net today and was pleased to see this general concept isn't crazy (or at least a bigger project came up with the same idea). That's a pretty obvious packagist clone using composer to deliver plugins, too.

I think the only real barrier here is getting a proper domain name for the plugin repo site.

[cgapperi]

Pretty darn amazing stuff going on here, Andy. I like the thinking.

On Tue, Oct 18, 2016 at 4:27 PM, Andy Theuninck notifications@github.com wrote:

Coincidentally, I ran across plugins.roundcube.net today and was pleased to see this general concept isn't crazy (or at least a bigger project came up with the same idea). That's a pretty obvious packagist clone using composer to deliver plugins, too.

I think the only real barrier here is getting a proper domain name for the plugin repo site.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CORE-POS/IS4C/issues/742#issuecomment-254644613, or mute the thread https://github.com/notifications/unsubscribe-auth/AAsqzEsZl7QslA6_yy9TZ-l5B3iXI8nmks5q1TnXgaJpZM4IpHXB .

‎"United we stand, divided we fall. Let us not split into factions which must destroy that union upon which our existence hangs." -- Patrick Henry

[gohanman]

Progress! https://plugins.core-pos.com/explore/

Caveats:

• I don't have all the plugins added yet
• There might be some github API token bits that need work
• I'm probably missing some cron scripts to keep search working and pull in new versions smoothly

For the most part though the site seems to work correctly. I think it makes more sense to introduce this in the context of #778 since this whole setup is designed to automatically dump code into pos/is4c-nf/plugins/ and fannie/modules/plugins2.0/. Doing that in the big monolith repo would just cause chaos.

Tangent: this is the first time I've used Let's Encrypt and it's freaking amazing.

[gohanman]

See #827