Package identification about latex3 HOT 9 CLOSED

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.

from latex3.

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…

from latex3.

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!

from latex3.

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

from latex3.

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:[email protected]}
%          {[email protected]}^^A
%    }^^A
% }
%
% \date{Released \filedate}
%
% \maketitle

from latex3.

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}

from latex3.

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

from latex3.

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.

from latex3.

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.

from latex3.