| [22:12:16] | <barkerd427[m]> | Greg: Been reading `common_form_helpers` and I want to use it. I've got three quick forms on my instance — medical, milk, weight — and the same `entity_autocomplete` -> `target_id` normalization is copy-pasted in all three... (full message at |
| [22:12:16] | <barkerd427[m]> | <https://matrix.org/oftc/media/v1/media/download/AdcSgr4NH_BSBKi8PNYEuWCg...) |
| [22:22:34] | <barkerd427[m]> | * Greg: Been reading `common_form_helpers` and I want to use it. I've got three quick forms on my instance — medical, milk, weight — and the same `entity_autocomplete` -> `target_id` normalization is copy-pasted in all three, and you've already got `AutocompleteValueTrait` for it. Also looks like `PickerWithAddNewTrait` and `FixedUnitInputTrait` replace things I hand-rolled. |
| [22:22:34] | <barkerd427[m]> | Your README says it gets extracted to contrib once a second consumer shows up. Happy to be that one, and I'm a useful test case since I'm livestock, single farm, no org scoping, so it'd exercise whether the helpers actually travel outside soil-health. |
| [22:22:34] | <barkerd427[m]> | Plan: migrate my three forms onto it and write up which traits worked unchanged vs which needed something. Want that report? And I'd do the extraction MR if it's useful. |
| [05:45:12] | <mstenta[m]> | I wanted to mention on the dev call... one pattern that is sometimes used in the Drupal ecosystem is to make a contrib utilities module that serves as a bucket to put additional features into that build on top of a core Drupal module |
| [05:45:18] | <mstenta[m]> | eg: https://www.drupal.org/project/migrate_plus |
| [05:48:19] | <mstenta[m]> | the Entity API module is another example of this... essentially serving as a place to put functionality that is useful to others but hasn't made it into the upstream core entity code yet |
| [05:48:48] | <mstenta[m]> | https://www.drupal.org/project/entity |
| [05:49:53] | <mstenta[m]> | Gr barkerd427: what you're steering towards is something like a farm_quick_extras contrib module |
| [05:50:04] | <mstenta[m]> | * @gbathree:matrix.org@barkerd427:matrix.org: maybe what you're steering towards is something like a farm_quick_extras contrib module |
| [05:52:49] | <mstenta[m]> | The nice thing about that approach/pattern is it also encourages organizing features in an atomic way, which makes them easier to reuse, and also easier to review one at a time and consider pulling upstream into farmOS core itself |
| [05:55:31] | <mstenta[m]> | but also, because it's contrib, it has a bit more freedom to experiment ("move fast and break things") than core, which is a bit more constrained |
| [11:03:47] | <barkerd427[m]> | That's the pattern I was hoping existed. `migrate_plus` is a good model. It dovetails with the migration I described: the portability write-up will show exactly which components could move into a `farm_quick_extras`-style bucket unchanged, and which would need work first. |
| [11:03:47] | <barkerd427[m]> | Mechanics question, since you've thought about this pattern: would you picture it drupalcode-native (like `farm_eggs`), or developed on GitHub with a drupal.org project handling releases and packaging (like farmOS core)? As I understand it, composer packaging (`drupal/*`) needs the repo and tagged releases on drupal.org's git; a project page that just links out to external code doesn't get one. And that `composer require |
| [11:03:47] | <barkerd427[m]> | drupal/farm_quick_extras` line is what would eventually let a site like mine swap a vendored copy for a real dependency. My own modules so far are only linked from drupal.org rather than hosted there, so I'd genuinely like to know which way you'd steer this. Also, what org structure should this live in. I have no preference on where it lives. |
| [11:05:09] | <mstenta[m]> | It's possible to pull composer dependencies from GitHub too - doesn't need to be on drupal.org |
| [11:05:34] | <mstenta[m]> | Probably best to start there, and you and Greg can coordinate on that |
| [11:05:56] | <mstenta[m]> | then, if there's more interest, and it makes sense, it can be promoted to drupal.org for wider use |
| [11:06:38] | <mstenta[m]> | the benefits of drupal.org are a) simpler composer require drupal/farm_quick_extras command, and 2) translations are possible |
| [11:06:50] | <mstenta[m]> | but those are only useful when you have a wider audience anyway |
| [11:07:07] | <mstenta[m]> | in the meantime, you can just add an additional "repository" line to your composer.json to point to the github repo |
| [11:07:29] | <mstenta[m]> | https://stackoverflow.com/questions/12954051/use-php-composer-to-clone-g... |
| [11:08:08] | <barkerd427[m]> | Ah, ok. Thank you. |
| [11:09:14] | <mstenta[m]> | (composer already knows about packages and drupal.org as upstream repositories to search for packages by name in... but if you have a github repo you need to add that to the list of repositories in composer.json) |
| [11:09:22] | <mstenta[m]> | s/packages/packagist/ |
| [11:09:28] | <mstenta[m]> | packagist is the official composer repo |
| [11:09:36] | <mstenta[m]> | drupal.org is declared in your composer.json |
| [11:09:51] | <mstenta[m]> | (if you used the default one from https://github.com/farmOS/composer-project) |
| [16:24:13] | * Conleone[m] has quit (reticulum.oftc.net charon.oftc.net) |
| [16:24:13] | * barkerd427[m] has quit (reticulum.oftc.net charon.oftc.net) |
| [16:24:13] | * mstenta[m] has quit (reticulum.oftc.net charon.oftc.net) |
| [16:24:31] | * Conleone[m] has joined #farmos |
| [16:24:31] | * barkerd427[m] has joined #farmos |
| [16:24:31] | * mstenta[m] has joined #farmos |
| [16:31:12] | * Conleone[m] has joined #farmos |
| [16:31:12] | * barkerd427[m] has joined #farmos |
| [16:31:12] | * mstenta[m] has joined #farmos |