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

Feedback dependency management approach from here into bazel core. #10

Open
hsyed opened this issue Sep 18, 2017 · 4 comments
Open

Feedback dependency management approach from here into bazel core. #10

hsyed opened this issue Sep 18, 2017 · 4 comments

Comments

@hsyed
Copy link

hsyed commented Sep 18, 2017

I'm hoping we can work some parts of the dependency management approach here into bazel core.

Bridge to issue in bazel core / migration-tooling.

@pcj
Copy link
Contributor

pcj commented Sep 18, 2017

Hi @hsyed thanks for the feedback. Sounds like a pain point for you is copying back the transitive closure into the rule, which you are proposing some sort of lock file. I agree it's a little annoying, lock file could be a good idea.

However, let's say for a moment that the lockfile had the format sha1:org:name:version, like the format of the transitive_deps attribute. One would still probably be copying back those values into the lock file every time you changed the deps attribute and had a different set of transitive dependencies.

So, question is, how to make lock file maintenance less annoying than the current state of affairs?

@pcj
Copy link
Contributor

pcj commented Sep 27, 2017

@hsyed ping

@hsyed
Copy link
Author

hsyed commented Sep 30, 2017

@pcj sorry for the delay.

If we had a lock file of some form couldn't we generate it and get rid of the copy pasting ? The user manages tuning the dependencies but beyond that the boilerplate could be generated.

Taking some inspiration from the go rules gazelle tool. Could we express dependencies in a yaml file with the high level co-ords of along with force entries. This repo could provide a tool of some form that generates two skylark files.

  1. The external repo macro file: contains a macro with all the maven_repository rules.
  2. The loader macro file: contains load call for all the external repos and a macro that primes them all.

Would this be doable ?

@pcj
Copy link
Contributor

pcj commented Sep 30, 2017

Have you tried https://github.com/johnynek/bazel-deps by @johnynek? That approach is fairly similar to what you are describing.

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