I propose we rename
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—
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::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) is a separate high-level project, rather than comparing
hanami/hanami, which is a bit vague. It’s on the same level, though much simpler, than
Let me know your thoughts Thanks for considering.
@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.
Sorry it’s not clear.
The proposal is just to:
- Rename the
hanami/hanami repo to
- Move as much as we can under the
Hanami::Application namespace (so move them within
- Keep the gem called
hanami. Don’t create a
hanami-application gem, just host the
hanami gem at
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.
@cllns Which problem are we trying to solve?
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/foo only defines files in the
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).
Withdrawing this because
Hanami::Application:: as a namespace has been removed in favor of just
Hanami:: for the full-stack framework