Discussion of keeping os_project_base vs os_base

[jyee]

There was a suggestion of moving os_project_base (which is renamed on make-install-profile to your projectname_base) back to os_base. Moving is back would make it easier to merge upstream changes in turnip back into the *_base feature. It would also give a stable feature for other os_* features to reference as a dependency.

Personally, I think that the *_base will likely change enough for individual projects that it will be unique and there shouldn't be many/any upstream changes to merge. Looking at the os_base commit log, changes directly to os_base were pretty rare. As for dependencies, I think that os_* features should be able to live on their own without os_base. e.g. os_blog should probably declare it's own namespaced body field base.

I'd like more discussion around this though, cuz i'm sure that I'm missing some of the benefits/detractors.

[adamdicarlo]

:+1: for decoupling features. I think namespaced fields are a good thing.

[jessehs]

:+1: I totally agree. I like sharing field bases on a per-project basis, but I don't necessarily think reusable features should try and couple with other reusable features for something as simple as a body field.

[jyee]

So, with decoupled features, are there any other good reasons we should keep os_base called os_base vs. automatically renaming it to the projectname_base? The one mentioned so far was upstream merges, so any fixes to os_base could be merged into ongoing projects. I've never done that, but it could be handy... it also could be really problematic with merge conflicts, since project bases will have a lot of customization.

[jessehs]

I can't think of many fixes in a base feature, aside from version updates to the make file. Seems like merging in changes wouldn't be any easier than manually updating module versions.

[jhedstrom]

I still think we should keep it as os_base, since there is code in there that may get updated/improved during the course of projects, that would be nice to be easily mergeable (even if done manually). If we are to rename it on every install, let's call it project_core, since project_base is intended for the profile rather than the core feature.

[jyee]

Yeah, currently it seems a lot of projects have been using project instead of project_base for the profile, which allowed that namespace to be used for what was project_core. Currently the make-install-profile script is just mass renaming any file with os_project in the name... which is why turnip has it as os_project_base, it'd be easy to move it to os_project_core.

I've never tried to upstream merge, but since renames are captured with git mv, shouldn't they still work when the core/base is renamed?

[jhedstrom]

The os_testing module (sub module of os_project_base) should probably be pulled out into a separate repository regardless of the path we take with os_project_base vs os_base.

Another point in favor of keeping os_base as something other features can depend on is user roles. Without that, the only role we can rely on is administrator, meaning features ship with incomplete permissions, or features don't export permissions, or features define their own roles. This is actually how the site editor role (which removal of has also been discussed) came about.

[adamdicarlo]

I think we can have both by making os_base a soft dependency. With custom code, we could check whether roles with certain names exist in order to determine which roles to give the permissions... this could be done in an _alter hook (the cleanest?) or it could be under the features radar as a hook_install task that sets permissions through code.

Of course, there could be an ordering complication there (if os_foo gets enabled before os_base).

[jhedstrom]

It's been decided:

os_base will remain os_base, allowing other features to have the dependency as needed. It is still hackable though, since it lives in the repo and upstream changes can be pulled in as needed manually.

foo_base or just foo is the standard for install profiles, foo_core is the standard for the core project-specific feature module.