You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During updating module dependencies of buffalo projects, I found that "buffalo" still uses "meta" version v0.3.x even though we already have "meta" v2. So I tried to migrate "buffalo" to "meta" v2, but I found build tag things do not exist on v2.
While I am checking the code and commit history, especially #8, I feel like the direction of this version is making "meta" more general and/or universal. (Not sure if this expression is perfectly fit. My English dictionary Is too limited) What I found is:
utilized "here" for golang-specific information.
made "meta" a general application-specific information container.
removed "build tag" related things since it is more likely buffalo specific thing.
So I am thinking I need to implement or move build tag things into "buffalo" itself when migrating "buffalo" to "meta" v2.
Is my understanding correct? Can you please explain the direction?
With my current understanding about meta/v2, It seems like migrating buffalo to meta/v2 is fine but migrating cli (along with clara) requires more work. Once I got the confirmation for my understanding, I will migrate buffalo as a part of gobuffalo/buffalo#2152. However, the migration of cli could be separated from that.
The existing code uses gobuffalo/meta to determine the module name, but
strips the fully qualified name from it. This is fine when dealing with
a buffalo project at the top level of a git repository/go module. However, if
multiple projects share a single go.mod file higher up the directory
tree this detection fails.
Using a build-time flag, restore the original fully qualified name of
the module so the buffalo project can be built as a sub-package. Further
ensure that actions/models/grifts are included in this.
An alternative solution would be to implement this as config option in
gobuffalo/meta. I believe this is the cleaner solution, however, given
gobuffalo/meta#11 the current state of meta
seems in question. I've implemented this directly in gobuffalo/cli
instead.
During updating module dependencies of buffalo projects, I found that "buffalo" still uses "meta" version v0.3.x even though we already have "meta" v2. So I tried to migrate "buffalo" to "meta" v2, but I found build tag things do not exist on v2.
While I am checking the code and commit history, especially #8, I feel like the direction of this version is making "meta" more general and/or universal. (Not sure if this expression is perfectly fit. My English dictionary Is too limited) What I found is:
So I am thinking I need to implement or move build tag things into "buffalo" itself when migrating "buffalo" to "meta" v2.
Is my understanding correct? Can you please explain the direction?
Any idea @paganotoni ?
The text was updated successfully, but these errors were encountered: