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

Consider allowing intervening directories in _sources #75

Open
michaelpj opened this issue Aug 22, 2023 · 2 comments
Open

Consider allowing intervening directories in _sources #75

michaelpj opened this issue Aug 22, 2023 · 2 comments

Comments

@michaelpj
Copy link
Collaborator

Currently the structure of _sources is just _sources/<package>/<version>. Suppose we allowed _sources/**/<package>/<version>. Then you could do things like this:

_sources/plutus
- plutus-core/...
- plutus-ledger-api/...
_sources/hackage-patches
- flat/...

And so on.

What's the benefit here? One is purely psychological: it lets people group stuff in a way that maybe makes more sense to them. The other is that it makes it much simpler to define e.g. a CODEOWNERS file, where you could match on plutus/* rather than having to list every package.

The intervening directories would of course have no effect on the build, so you could move them around freely.

@andreabedini
Copy link
Member

TBH I think the _sources/<package>/<version> schema is mostly historical. This also gave us headaches because we have to make sure the location of meta.toml matches the resulting package id.

We could just glob **/meta.toml and only make sure there are no duplicates at the end; but it will give a worse user experience since nothing is going to tell you what packages you are looking at (since the name will only known when we cabal sdist). Also this doesn't help you with CODEOWNERS.

@michaelpj
Copy link
Collaborator Author

I think the <package>/<version> structure is nice. If we don't do that, I would like to see that information go in meta.toml (even if it's strictly redundant since we can get it from the sdist).

I would be mildly in favour of a "meta.toml contains package version information, meta.tomls can go anywhere" approach, but it would probably be a hassle to migrate to and not obviously worth it.

Also this doesn't help you with CODEOWNERS.

Well, it does: it means the structure is up to the people managing the repository source, which means you can do whatever you want. Of course, there would be nothing enforcing the structure, but this isn't really intended to defend against malicious people, just to get reviewers assigned.

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

No branches or pull requests

2 participants