Feedback dependency management approach from here into bazel core.

[hsyed]

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]

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]

@hsyed ping

[hsyed]

@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]

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