Added algorithm2e, as well as dependencies

[beneisner]

One of the standard packages for writing down algorithms. Required adding in relsize and ifoddpage.

[patbro]

Hi Ben!

Thanks a lot for contributing to bazel-latex! Did you perhaps already tried to add this package locally instead? https://github.com/ProdriveTechnologies/bazel-latex#local-packages

Let me know whether this works or perhaps somehow might not work for you.

[beneisner]

This is what I'm currently doing in my local projects, although it is a bit cumbersome because I have multiple projects where I'd like to use this package.

Is there any reason not to upstream it into bazel-latex?

[patbro]

Ah, I see. Would it be possible for you to push that patch to your fork and use that in your projects?

If that doesn't work for you, then I'm more than happy to merge the suggested change. Though, I kind of see the suggested PRs for adding packages as a user configuration kind of thing. You could argue you don't want to merge each user configuration upstream. Hence I added the suggestion to utilize patches instead in the README.

Would love to hear how you think about this.

[patbro]

Merging for now as mentioned here #63 (comment).

[beneisner]

Thanks a ton for merging this! I appreciate you taking the time to review + consider. Regarding your last message - as mentioned in #63, exposing multiple packages is somewhat hard with the current build rules.

Is there some way to autodetect all the recursive dependencies for a package? That might make it easier to include additional dependencies?

Otherwise, maybe you could consider adding some Skylark magic to achieve something like what https://github.com/bazelbuild/rules_python does (like requirement("numpy")), and expose some sort of build rule "texlive_package" that allows you to add your own packages with some magic searching over the TexLive, or without adding a patch to the workspace?

[patbro]

Regarding your last message - as mentioned in #63, exposing multiple packages is somewhat hard with the current build rules.

It can definitely be cumbersome. Though, if a package requires certain dependencies, just add them to the latex_package (like for pgfopts), right? Do you perhaps have an example where this is not that trivial?

Is there some way to autodetect all the recursive dependencies for a package? That might make it easier to include additional dependencies?

Otherwise, maybe you could consider adding some Skylark magic to achieve something like what https://github.com/bazelbuild/rules_python does (like requirement("numpy")), and expose some sort of build rule "texlive_package" that allows you to add your own packages with some magic searching over the TexLive, or without adding a patch to the workspace?

I think it should be possible, using some Starlark, to expose all of the @texlive_ packages. I'm afraid this would create a huge mess in your BUILD.bazel, but it gives the user complete flexibility over the packages used. Then there is also no need to autodetect any recursive dependencies.

[Kernald]

It can definitely be cumbersome. Though, if a package requires certain dependencies, just add them to the latex_package (like for pgfopts), right? Do you perhaps have an example where this is not that trivial?

I've personally been trying to add xcookybooky - that's what all my recent PRs have been about - and some packages, especially ones involving fonts, are definitely not trivial. I'm on holiday now and don't have access to a computer to list specific packages, but I'm happy to provide a list of packages I've been struggling with in a few days.

[Kernald]

Here are a few packages I've been struggling:

• ifsym. It depends on a font, but @texlive_texmf__texmf-dist__fonts__tfm__public__ifsym is apparently not enough - not sure what else it needs.
• cookingsymbols probably has the same issue, @texlive_texmf__texmf-dist__fonts__tfm__public__cookingsymbols is apparently not sufficient in terms of font declaration.
• translations. It's looking for scrlfile.sty which seems to come from koma-script, which seems to be its own massive thing that I haven't had time to investigate enough.

[beneisner]

I think it should be possible, using some Starlark, to expose all of the @texlive_ packages. I'm afraid this would create a huge mess in your BUILD.bazel, but it gives the user complete flexibility over the packages used. Then there is also no need to autodetect any recursive dependencies.

This is probably the best compromise between easy usage + implementation complexity. Since most packages work just fine, I don't think the mess will be all that frequent, and it's definitely easier to do than the clone+modify+export-patch workflow currently recommended (and doesn't require understanding of how bazel-latex works).

I might have some time in Feb/March to take a stab at this, if it's not on your agenda.

[patbro]

This is probably the best compromise between easy usage + implementation complexity. Since most packages work just fine, I don't think the mess will be all that frequent, and it's definitely easier to do than the clone+modify+export-patch workflow currently recommended (and doesn't require understanding of how bazel-latex works).

I might have some time in Feb/March to take a stab at this, if it's not on your agenda.

Actually, it seems like all @texlive_ packages are already exposed.

When trying to build the example without including biblatex using @bazel_latex//packages:biblatex, but instead using the @texlive_ references as defined here, the build succeeds without any errors :)

That being said, by loading latex_package, one could build their own package(s) in their own BUILD.bazel file. Isn't that just what we want in the end or am I missing anything?

[Kernald]

Actually, it seems like all @texlive_ packages are already exposed.

When trying to build the example without including biblatex using @bazel_latex//packages:biblatex, but instead using the @texlive_ references as defined here, the build succeeds without any errors :)

This works, but gets tricky once a package has dependencies. E.g. caption is defined with a dependency on :keyval and @texlive_texmf__texmf-dist__tex__latex__caption. If you only use @texlive_texmf__texmf-dist__tex__latex__caption, you'll have compilation errors. To solve them, you have to figure out that caption depends on keyval, which in turn depends on soul, which in turn depends on ec...

This is tedious enough for packages with simple dependencies (e.g. a single target in @texlive, but when a package starts depending on fonts etc, it gets tricky quite quickly.

[patbro]

This works, but gets tricky once a package has dependencies. E.g. caption is defined with a dependency on :keyval and @texlive_texmf__texmf-dist__tex__latex__caption. If you only use @texlive_texmf__texmf-dist__tex__latex__caption, you'll have compilation errors. To solve them, you have to figure out that caption depends on keyval, which in turn depends on soul, which in turn depends on ec...

This is tedious enough for packages with simple dependencies (e.g. a single target in @texlive, but when a package starts depending on fonts etc, it gets tricky quite quickly.

This is still what one needs to do when adding a new package to bazel-latex. That's unfortunately just the nature of how TeX Live works, and that's why many people just install all (recommended) TeX Live packages.

Automatically figuring out the dependencies for any given package is beyond the scope of bazel-latex. Though, the packages file does an attempt at simplifying this for bazel-latex users. :)

That being said, some improvements that could be made:

1. Accepting and merging PRs that add any package, including proper tests (to ensure the dependencies are complete).
2. Exposing latex_package to the user so they can define any given package they like in their own BUILD.bazel file. If desired they can create a PR to include it in bazel-latex.
3. Update the TeX Live tarball some time...

Happy to hear your thoughts on this.