Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

What is the direction of meta v2? #11

Open
sio4 opened this issue Nov 8, 2021 · 2 comments
Open

What is the direction of meta v2? #11

sio4 opened this issue Nov 8, 2021 · 2 comments
Milestone
v2

Comments

@sio4
Copy link
Member

sio4 commented Nov 8, 2021

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:

  1. utilized "here" for golang-specific information.
  2. made "meta" a general application-specific information container.
  3. 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?

Any idea @paganotoni ?
@sio4
Copy link
Member Author

sio4 commented Nov 10, 2021

Thanks for releasing here v0.6.5 @stanislas-m. (I also just PRed #12 using that.)

Could you please guide me if my understanding of the direction of meta/v2 is correct? (this issue)

@sio4
Copy link
Member Author

sio4 commented Nov 10, 2021

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.

@sio4 sio4 mentioned this issue Nov 11, 2021
Closed
@sio4 sio4 added this to the v2 milestone Sep 4, 2022
JarrahG pushed a commit to JarrahG/buffalocli that referenced this issue Jul 31, 2023
build: Allow custom module import names
5d40118 
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.
@JarrahG JarrahG mentioned this issue Jul 31, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v2
Development

No branches or pull requests
1 participant
@sio4