Skip to content

Add the minifp package#58

Merged
patbro merged 1 commit intoProdriveTechnologies:masterfrom
Kernald:minifp
Aug 7, 2021
Merged

Add the minifp package#58
patbro merged 1 commit intoProdriveTechnologies:masterfrom
Kernald:minifp

Conversation

@Kernald
Copy link
Copy Markdown
Collaborator

@Kernald Kernald commented Aug 2, 2021

No description provided.

@Kernald Kernald mentioned this pull request Aug 2, 2021
@patbro
Copy link
Copy Markdown
Member

patbro commented Aug 3, 2021

Hi @Kernald! Thanks a lot for contributing to bazel-latex!

In the past, I've already been looking into another way for users to add packages themselves, rather than through a PR. Did you by any chance take a look at the README, which describes another - easier - way to add packages to bazel-latex?

Let me know your thoughts on this. I'm open to any other suggestions as well.

@Kernald
Copy link
Copy Markdown
Collaborator Author

Kernald commented Aug 3, 2021

Hi @patbro !

I've indeed noticed this section, I was just not sure whether it was still the intention to accept PRs if people want to contribute or not. While I would definitely not mind keeping those package definitions in my own repo, some of them are a bit annoying as they need a whole chain of dependencies (I'm currently trying to get xcookybooky to work, but still haven't finished integrating every dependency...).

I also understand that maintaining a list of every single LaTeX package is obviously not an option either, and every single addition creates more potential maintenance burden. So I'm definitely happy to close those PRs if you'd prefer go that way.

@patbro
Copy link
Copy Markdown
Member

patbro commented Aug 3, 2021

I didn't reach a final conclusion on whether to accept or reject such PRs yet. I believe it's mainly important what's the easiest way of working for you and all others that are using bazel-latex. So, consider this an open invitation to comment on this :)

In my opinion, the user should have more control over the packages they want to use. Because currently this is pretty much 'baked into' bazel-latex.

So, it might be wise to reconsider the implementation of the packages. Instead of allowing the user to specify a package defined by bazel-latex as such: @bazel_latex//packages:hyperref. I think it should be possible to directly expose the whole library of TeX Live packages to the user. For example, like: @bazel_latex//packages:texlive_texmf__texmf-dist__tex__latex__hyperref.

In the end, the user is responsible for defining the correct chain of dependencies in order to successfully build to document. Bazel-latex is only here to support building the document. However, the current implementation of the packages makes building the document easier for the user.

@Kernald
Copy link
Copy Markdown
Collaborator Author

Kernald commented Aug 3, 2021

Defining packages is most of the times trivial, but sometimes it can get a bit complex - e.g. see #48, I'm still not sure what's going on there. Particularly for packages adding fonts that need multiple archives, it's not straightforward. Add to that the number of dependencies that a package can have, each of them potentially pulling other dependencies, it's a tedious process.

Because of that, I definitely think there's some value in having some sort of package reference somewhere. However, I do understand that it's a burden - while there's not much active maintenance to do once a package is added, that's potentially a lot of (frankly quite boring) PRs to review.

I think the question is, do we want to maintain a package collection in this repo with the rules, or outside? If outside, should it be managed by ProdriveTechnologies as well, or by someone else? (Either way, nothing guarantees that it's ever gonna remain a single reference, if it's unbundled from the rules.) I see a few pros and cons to unbundling the package definitions in another repo:

  • Pro: no more PRs in the rules repo that aren't directly related to the rules. Easier to maintain.
  • Pro: versioning the rules and updating them becomes (probably) easier.
  • Pro: it shows to users that adding a package that isn't bundled in the rules is easy.
  • Con: the package definitions are less discoverable. Finding a ruleset without any of the packages might be a barrier to entry.
  • Con: more set-up for users - that's another repo to depend on.
  • Con: the packages are kind of tests for the current ruleset. This can be easily addressed with a slightly more complex (but one-time) CI set-up.

All in all, I don't have a huge preference either way - most of it would affect first-time users, the end-result for existing users is pretty much the same.

@patbro
Copy link
Copy Markdown
Member

patbro commented Aug 7, 2021

The current way of working isn't that strange altogether. It actually simplifies including a package for the user. Because you will probably not use the packages without bazel-latex, it makes sense to keep everything in one repo.

Let me review and (if possible) merge your open PRs. Afterward, I will take another look at some of the issues you're facing when I have more time available.

@patbro patbro merged commit 244fca0 into ProdriveTechnologies:master Aug 7, 2021
@Kernald Kernald mentioned this pull request Dec 15, 2021
@Kernald Kernald deleted the minifp branch August 11, 2022 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants