Hi Jeroen,

On 2015-09-06, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> I don't think that package-version.txt should be used as answer to 
> package.version() in Sage. I consider this file to be build metadata, 
> while package.version() should provide upstream's idea of the version 
> number, using some function or data from the upstream sources.

OK, that means you are in favour of diversity, because different
upstreams have different ideas.

Note that Singular already has two different ideas of version information:

sage: singular.eval('system("--version")')
'Singular for x86_64-Linux version 3-1-7 (3170)  Aug 22 2015 
12:22:22\nwith\n\tfactory(@(#) factoryVersion = 3.1.7),libfac(3.1.7,December 
2013),\n\tGMP(5.1),NTL(9.3.0),FLINT(2.5.2),64bit,static 
readline,Plural,DBM,\n\tdynamic modules,dynamic 
p_Procs,OM_CHECK=0,OM_TRACK=0,random=175857634\n\tCC= gcc -O2 -g -fPIC -pipe 
-DNDEBUG -DOM_NDEBUG -Dx86_64_Linux -DHAVE_CONFIG_H,\n\tCXX= g++ -O2 -g -fPIC 
-I.. -I/home/king/Sage/git/sage/local -pipe -DNDEBUG -DOM_NDEBUG -Dx86_64_Linux 
-DHAVE_CONFIG_H (4.8.3 20140627 [gcc-4_8-branch revision 212064])\nargv[0]   
:\t/home/king/Sage/git/sage/local/bin/Singular\nSearchPath:\t/home/king/Sage/git/sage/local/share/singular\nSingular
  :\t/home/king/Sage/git/sage/local/bin/Singular\nBinDir    
:\t/home/king/Sage/git/sage/local/bin\nRootDir   
:\t/home/king/Sage/git/sage/local\nDefaultDir:\t/home/king/Sage/git/sage/local\nInfoFile
  :\t\nIdxFile   :\t\nHtmlDir   :\t\nManualUrl 
:\thttp://www.singular.uni-kl.de/Manual/3-1-7\nExDir     :\t\nPath      
:\t/home/king/Sage/git/sage/local/bin:/home/king/Sage/git/sage/local/libexec/ccache:/home/king/Sage/git/sage/build/bin:/home/king/Sage/git/sage/src/bin:/home/king/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/qt3/bin\nEmacsDir
  :\t\nAvailable HelpBrowsers: dummy, emacs, \nCurrent HelpBrowser: dummy '

versus

sage: singular.eval('system("version")')
'3170'

Currently we use the system("--version"), which gives an error when first 
executed;
system("version") does *not* give an error when first executed and is
less talkative.

Would you say that <interface>.version() should be consistent in the
type of the return value, i.e., that it should always return a string?
Or do you think it is ok that some interfaces return a string, some
return a pair formed by a tuple and a string, some return an interface
element that looks like a list?

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to