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

Using external libraries that depend on other libraries #154

Closed
0xd3e opened this issue Feb 22, 2022 · 2 comments · Fixed by #182
Closed

Using external libraries that depend on other libraries #154

0xd3e opened this issue Feb 22, 2022 · 2 comments · Fixed by #182

Comments

@0xd3e
Copy link

0xd3e commented Feb 22, 2022

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 from github.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

RUNTIME ERROR: couldn't open import "github.com/grafana/jsonnet-libs/ksonnet-util/kausal.libsonnet": no match locally or in the Jsonnet library paths

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.

github.com
└── grafana
   └── jsonnet-libs -> /path/to/bazel/external/com_github_grafana_jsonnet-libs

Do you know any way to achieve that?

@0xd3e
Copy link
Author

0xd3e commented Feb 22, 2022

It might also be possible to implement something that uses jsonnet-bundler behind the scenes similar to what rules_python did with their pip_install function.

This constructs a repository with the given name (e.g. my_deps) which can be used to get the dependencies.

I can think of creating a repository like @jb, so that dependencies might be selected by using for example @jb//github.com/grafana/jsonnet-libs:pkg.

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.

EdSchouten added a commit to EdSchouten/rules_jsonnet that referenced this issue Apr 4, 2024
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
EdSchouten added a commit to EdSchouten/rules_jsonnet that referenced this issue Apr 4, 2024
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
@EdSchouten
Copy link
Collaborator

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 @foo//my/package:foo.jsonnet, it can now be imported through my/package/foo.jsonnet. (Or you can abbreviate it even further by adding imports).

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

Successfully merging a pull request may close this issue.

2 participants