I propose we rename hanami/hanami to hanami/application. The gem and CLI took would still be called hanami. This is a pretty foundational shift in terms of naming, since this gem is the ‘main’ Hanami codebase. It’s what ties the libraries together into a full-stack application.
Over the 6 years I’ve been contributing to Hanami, it’s always a little clunky to say “a full-stack Hanami application” to mean a hanami/hanami application and having to either explain or assume the reader understands the distinction between that and the constituent libraries.
If we do this renaming, we could all be consistent with messaging and say "in a Hanami::Application" to mean the full-stack framework and be able to speak in concretely rather than abstractly. Obviously we could try to be consistent about this regardless, but it’s less clear what that namespace means, or where the code is located.
There are five folders in lib/hanami/. One is lib/hanami/application/, which can stay where it is. The other four folders—assets/ , cli/ , configuration/ and web/—can all move into lib/hanami/application (or find other homes). The namespaces would follow suit, of course, and get nested within Hanami::Application::. I think this is a good practice, since right now hanami/hanami re-opens namespaces from other gems and defines some classes/modules within Hanami::CLI and Hanami::Assets. Instead of this, we could inherit as needed, e.g. Hanami::Application::CLI < Hanami::CLI etc.
There are a number of files in lib/hanami/ too. Many of those can move into lib/hanami/application, but it’s also OK to keep some at the top level.
This renaming could also help clarify that Hanami::API (at hanami/api) is a separate high-level project, rather than comparing hanami/api and hanami/hanami, which is a bit vague. It’s on the same level, though much simpler, than Hanami::Application.
@cllns I’m not sure to grasp the proposed changes.
Do you want to have hanami-application gem to live in hanami/application repository?
Also, do you want hanami gem to still exist? But it’s gonna be a meta gem that bundles all the others. This is gonna be the primary gem that people install and deal with?
Please remember that the code that exists right now in hanami/hanami repo is leftover or target to be moved. I’m talking about assets and cli directories.
Rename the hanami/hanami repo to hanami/application
Move as much as we can under the Hanami::Application namespace (so move them within lib/hanami/application
Keep the gem called hanami. Don’t create a hanami-application gem, just host the hanami gem at hanami/application
The other approach you mention, creating a new hanami-application gem extracted from hanami/hanami (and turn hanami/hanami into a meta gem) is another option but one that adds complexity that may not be worth the benefits.
My second paragraph in the original post described the problem:
To elaborate though:
For monorepo open source projects like rails, naming the repo rails/rails is an obvious choice. But for Hanami, I feel like it’s unclear to new potential users what hanami/hanami is (and what it isn’t), since Hanami is intentionally modular.
I can understand a “we don’t need to fix it if it’s not broken” mindset, and we’re all certainly used to the current approach. But I’m trying to consider the experience new users have, and also establishing strong conventions to guide us.
In general, I think it’d nice to move to a strong convention of:
hanami/fooonly defines files in the Hanami::Foo namespace
hanami/foo doesn’t open any other namespaces
The benefit of that is that it’s clear to everyone where code lives, and where any given constant is defined.
We do that somewhat, but there are still some stragglers and I think pre-2.0 is a good time to reconsider how the repositories are named (and what namespaces they define).
Thanks for considering.