Package identification

[wspr]

I guess I agree with Rasmus here:

I was writing a document where I had \newcommand{\filename}{\texttt}. After including siunitx, I started getting the error "\filename already defined". A little (very little, actually) digging showed that the problem was the call of \GetIdInfo (from l3names.sty) in l3keys2e , which (ab)uses the user-namespace macro \filename to return the result of the string parsing. Since \filename (and friends) is only used in the immediately following \ProvidesExplPackage, it would probably be better to use some scratch macros. Or, changing \GetIdInfo so that the caller must provide macros to store the results in, or a template for such macros (say \Info_Return_, which would lead to \Info_Return_filename etc.) Undefining \filename after is has been used is not enough (in case I had put my definition of \filename above the first package using l3-syntax, it would be silently re- or undefined).

We've spoken about this before (Joseph had some good ideas at one point), and this is not the first time it has come up.

[josephwright]

The problem we have is that \GetIdInfo is doing two separate things: providing information for \ProvidesExplPackage and also for the typesetting package documentation. In contrast, the LaTeX2e macro \GetFileInfo is only ever used in typesetting documentation, and so can define \filename, etc. in a more-or-less arbitrary way. We currently need a 'user space' name for the returned information due to the way \ProvidesExplPackage works. Some possible options:

• Hard-code this information into files rather than using \GetIdInfo (leaves us with a file date/version problem).
• Pick some new names that will not be a problem, say \ExplFileName, etc.
• Use an alternative to \GetIdInfo that does not use scratch macros but instead directly use the information in \ProvidesExpl(Package|Class|File), and use \GetFileInfo in the normal way for the documentation

My personal preference is the first option: there was a suggestion on LaTeX-L a while ago to drop \GetIdInfo as it is tied to CVS/SVN approaches. This is what I do, for example, with siunitx. However, that might not fly with all of the interested parties. So perhaps that last alternative is better, with something like \ProvidesExplPackageFromID (etc.), at least for the moment. It's a bit long, but it would deal with the issue quickly and without too much argument.

[wspr]

I guess the easiest option is to use \ExplFileName. I agree with Philipp's comments a while back that since \GetIdInfo is so strongly tied to CVS/SVN it's not really appropriate as a general versioning tool. Would many packages actually use \GetIdInfo besides our own? I don't think changing this is a big compatibility problem…

[josephwright]

I'm also with Philipp on \GetIdInfo, but to kill it entirely we have to sell DCVS to all of the team. For the moment, let's go with \ExplFileName, etc., to at least solve the problem at hand! I'd also suggest we use \GetFileInfo in the documentation part of our files, so that if we do drop \GetIdInfo entirely the documentation version/date will continue to match the code!

[wspr]

Good idea. In time I guess we can think about improving \GetFileInfo but that will have to wait.

In fact, I reckon we could just use one of the other SVN-keywords packages for our needs and drop the SVN metadata when we're creating a format. It'd be nice to simplify that aspect of the package loading, and I'm sure the dedicated packages do a better job than we do with the string parsing. Hmm....

[josephwright]

True: I'd go for the svn-multi package, as it's up to date and seems to be well-supported. We'd then only need

\svnid{$<stuff here>$}
...
\ProvidesExplPackage{\svnfilefname}{\svndate}{\svnrev}

with the only issue being \filedescription, which would have to be moved from the header. You might therefore actually only retain the revision data

\ProvidesExplPackage{<file-name>}{\svndate}{\svnrev}{<file-description>}

BTW, I've already tested \GetFileInfo, and realise that it makes it easiest to include the file description in the typeset documentation:

% \GetFileInfo{\jobname.sty}
%
% \title{^^A
%   \fileinfo
%   \thanks{This file describes v\fileversion, last revised \filedate.}^^A
% }
%
% \author{^^A
%  The \LaTeX3 Project\thanks
%    {^^A
%      E-mail:
%        \href{mailto:latex-team@latex-project.org}
%          {latex-team@latex-project.org}^^A
%    }^^A
% }
%
% \date{Released \filedate}
%
% \maketitle

[josephwright]

I did a bit of experimenting, and for svn-multi we'd actually do something like

\RequirePackage{svn-multi}
\svnid{$Id: l3seq.dtx 0000 000-00-00 00:00:00Z joseph $}
\ProvidesExplPackage
  {l3seq}
  {\svnfileyear/\svnfilemonth/\svnfileday}
  {\svnfilerev}
  {The LaTeX3 kernel: sequences and stacks}

[josephwright]

I should add that I think this is probably one that can be covered as part of the 'big bang' (provided that happens soon!)

[josephwright]

It occurs to me that using svn-mutli would still leave us open to the danger that someone might do

\usepackage{svn-multi}
\svnid{$Id ... $ }
\usepackage{expl3}

and get a surprising result. So I think the best fix in the short term is to use a dedicated set of macros that will not conflict with anyone else.

[wspr]

I'm going to close this particular issue here — but we may want to go back to a formal module identification syntax that you've suggested before. Happy to either have it raised as another issue or just to keep it in the back of our minds.