-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Using external libraries that depend on other libraries #154
Comments
It might also be possible to implement something that uses jsonnet-bundler behind the scenes similar to what rules_python did with their This constructs a repository with the given name (e.g. I can think of creating a repository like Anyway... feedback about these ideas are appreciated. I can try to implement something, but I might need some help since I'm still not that familiar with Bazel and its internals. |
Right now you see that jsonnet_to_json() and jsonnet_to_json_test() implicitly call jsonnet with "-J .". This means that if these rules are used in combination with libraries that are declared in the root module, everything works as expected. But as soon as libraries are used from other modules, importing them becomes more tedious. The goal of this change is to ensure that if a Jsonnet project can be built within the root module, that module can also safely be used as a child module. We solve this by automatically adding the workspace root to the set of import paths for which one or more source files exist. Furthermore, by considering the root of every source file, we no longer need to use bin_dir and genfiles_dir. Fixes: bazel-contrib#44 Fixes: bazel-contrib#86 Fixed: bazel-contrib#139 Fixes: bazel-contrib#154 Fixes: bazel-contrib#178
Right now you see that jsonnet_to_json() and jsonnet_to_json_test() implicitly call jsonnet with "-J .". This means that if these rules are used in combination with libraries that are declared in the root module, everything works as expected. But as soon as libraries are used from other modules, importing them becomes more tedious. The goal of this change is to ensure that if a Jsonnet project can be built within the root module, that module can also safely be used as a child module. We solve this by automatically adding the workspace root to the set of import paths for which one or more source files exist. Furthermore, by considering the root of every source file, we no longer need to use bin_dir and genfiles_dir. Fixes: bazel-contrib#44 Fixes: bazel-contrib#86 Fixed: bazel-contrib#139 Fixes: bazel-contrib#154 Fixes: bazel-contrib#178
With #182 merged, this should be addressed. You can now just import files using workspace root relative paths. So if you have a file named |
I'm trying to find a way to use external libraries that depend on other libraries, where I cannot control the import path.
To give you an example, this library uses
k
, which is imported fromgithub.com/grafana/jsonnet-libs/ksonnet-util/kausal.libsonnet
.This import path is compatible to jsonnonet-bundler.
So using the jsonnet rules, it is possible to import the previously mentioned library for example, but the build would fail with something like
The easiest way I can think of would be to fetch the repository via
http_archive
and build a structure like the following with a link to the actual directory.Do you know any way to achieve that?
The text was updated successfully, but these errors were encountered: