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

[workspace.members] not supporting wildcards in Anchor.toml #2784

Closed
GabrielePicco opened this issue Jan 23, 2024 · 2 comments
Closed

[workspace.members] not supporting wildcards in Anchor.toml #2784

GabrielePicco opened this issue Jan 23, 2024 · 2 comments
Labels
cli duplicate This issue or pull request already exists

Comments

@GabrielePicco
Copy link
Contributor

GabrielePicco commented Jan 23, 2024

In a Anchor workspace, using workspace.members in the Anchor.toml does not work.

Adding the following to Anchor.toml:

[workspace]
members = [
    "programs/*",
]

results in:

thread 'main' panicked at cli/src/config.rs:314:25:
Error reading workspace.members. File "programs/*" does not exist at path "/test-new/Anchor.toml"

Specifying a single member without wildcard instead works:

[workspace]
members = [
    "programs/test-new/",
]

To my understanding from the doc, programs/* should be equivalent to the default behaviour.

This issue prevent to organize several anchor programs in subfolders.

The root cause seems to be the canonicalize_workspace which should probably use a flat_map and expand the wildcard. Happy to draft a PR if this is a potential solution.

@GabrielePicco GabrielePicco changed the title [workspace.members] not supporting wildcard in Anchor.toml [workspace.members] not supporting wildcards in Anchor.toml Jan 23, 2024
@acheroncrypto acheroncrypto added duplicate This issue or pull request already exists cli labels Jan 23, 2024
@acheroncrypto
Copy link
Collaborator

The root cause seems to be the canonicalize_workspace which should probably use a flat_map and expand the wildcard. Happy to draft a PR if this is a potential solution.

Yes, we can manually handle the /* case which is the most common case as you suggested. We could also add glob support so that we don't have to manually handle it but I'm fine with both solutions.

Feel free to send a PR for this but I'm closing this issue as it's duplicate of #2658.

@GabrielePicco
Copy link
Contributor Author

I missed the issue that was already opened. I've opened a PR addressing the simpler case: #2785.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants