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
Rework setversion #40
Comments
yes |
Actually I probably should change how this works a bit: it would be better to require a tag name and go with
which is then pretty similar to e.g. Git's syntax. |
I took a look at the code here and I actually don't mind the current approach. With the manifest code it's important to pass around file handles because you're operating directly onto files as they're written. In the case of setversion the functionality seems more "contained" and simply dealing with a line of text encapsulates/simplifies what's going on. It seems like using a file handle would add complexity for the user code — is there an advantage to doing this? |
@wspr The current code is limited to a line-by-line approach: one might expect that some users want to do more complex manipulation. As @FrankMittelbach notes, using |
Oh, good point — it’s pretty understandable people might want to have something like
\ProvidesExplPackage
{…}
{…}
{…}
{…}
and so on...
|
This is the first key step to making a stand-alone script. Note that one now needs to do "texlua l3build" or similar. Various bits and pieces outstanding!
This should allow both forms of usage, for the present, but without having to reload files.
We will still need to work on this, for example once l3build can be run by name.
Based on @wspr's excellent Lua code in #34, I realise that the current
setversion
customisation is not ideal. It should deal with a file handle not a line of text (reflects a TeX background!). At the same time, I remain unhappy about using-v
for 'versionhere .. I think
-tfor
--tag` might be better ...The text was updated successfully, but these errors were encountered: