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.

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

[Request] Support for conventional module paths - needed for godocs & binaryd #3737

Open
Olshansk opened this issue Nov 7, 2023 · 5 comments
Labels
request Feature request.

Comments

@Olshansk
Copy link

Olshansk commented Nov 7, 2023

Note: There may be certain flags/configs we haven't found that can fix this. If it is that easy, would really appreciate you directing in that direction!

Background

At pokt.network, we are currently using ignite to build the next version of the protocol using Rollkit on Celestia.

Issues

We recently hit 3 issues:

  1. Godocs - Ability to generate godocs generated at pkg.go.dev
  2. Binaryd - Ability to specify a binary named after completing (1)
  3. Scaffolding - Ability to continue using ignite scaffold after implementing (1) and (2)

Issue 1 - Godocs

In order to have docs generated at pkg.go.dev, we had to implement poktroll/pull/128 which involved:

  • Replace module pocket with module github.com/pokt-network/poktroll in go.mod
  • Replaced all instances of import "pocket/..." with import "github.com/pokt-network/poktroll/..."

Though we do have nice godocs now, it created downstream issues.

Ref: https://pkg.go.dev/github.com/pokt-network/poktroll

Issue 2 - Binary Name

After implementing the changes above, we had to rename all instances of pocketd with poktrolld as seen in poktroll/pull/157. We would like to be able to easily specify what this binary name should be

Issue 3 - Scaffolding

After making the changes in (1), we are no longer able to run commands such as ignite scaffold list olsh --module supplier supplier_address session_id root_hash --no-message --yes due to the discrepancy between pocket (the name we used during scaffolding) and poktroll, the name in the repo.

Screenshot 2023-11-07 at 3 48 24 PM

@Pantani
Copy link
Collaborator

Pantani commented Nov 11, 2023

@Olshansk, for the first issue, the problem was when you scaffold your chain, you should use the commands

ignite scaffold chain github.com/pokt-network/poktroll instead ignite scaffold chain poktroll

For the second one, you can use the output flag into the build command: ignite chain build --output ./poktroll

And maybe you need to change the name of your default module to the exact name of the chain so you can scaffold again in the default module, or you should specify the --module flag.

@Pantani
Copy link
Collaborator

Pantani commented Nov 17, 2023

@Olshansk any updates?

@Olshansk
Copy link
Author

@Pantani Apologize for the delay!

For the second one, you can use the output flag into the build command: ignite chain build --output ./poktroll

👍 cc @okdas for context

ignite scaffold chain github.com/pokt-network/poktroll instead ignite scaffold chain poktroll

  1. I have provided feedback to the rollkit.dev team to update their docs, which we used as a source for this. See Figure 1 below.

  2. Question: Given that our repository is already scaffolded and too mature to rescaffold, is there a solution? The current issue and manual steps we're taking are capture in Figure 2 below.

Figure 1

Screenshot 2023-11-20 at 11 43 52 AM

Figure 2

Screenshot 2023-11-20 at 12 01 44 PM

@Olshansk
Copy link
Author

@Pantani Have you had a chance to see my response on the updates?

@julienrbrt
Copy link
Member

Once you have scaffolded the chain, imho it makes sense that renaming the whole go module should be manual.
You can have a script for it to rename all packages + proto imports, as you said.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Feature request.
Projects
None yet
Development

No branches or pull requests

3 participants