Hi, On Tue, May 12, 2015 at 07:19:07AM -0700, Volker Braun wrote: > IMHO: > > * The package type (standard/optional/experimental) should be in a file > inside the package directory
+1. Actually, i have a prototype of this for the purpose of checking to the upstream website if a newerver version is out (i did it mainly for openssl, but it now covers most packages), and get some other information by browsing the source code (e.g. which are installed, how many patches, ...). > * The build system should check that it builds only standard packages Or even conversely, generate build/deps from such atomic informations, of course, we should mention both - the priority (toolchain, base, standard, optional, experimental) - the dependencies This would have the benefits over the current system to be able to provide dependencies not only for standard packages but also for optional ones, we could also mention pip dependencies there. If people think it is interesting and has a chance to be merged at some point, i can update my prototype to that aim. I was shy to propose it since it is written in Python, and, if it is used to compile the whole stuff, then Python will be a requirement, which seems currently pretty controversial. > * Old-style spkgs shouldn't be mashed together with new-style packages, > that is super confusing if you have both. +1. > * Instead, put all old spkgs in a separate category (sage -old-spkg or so), > or list them separately at the end of "sage -optional" +1, see my previous answer, or why not simply just trash old-style, while migrating interesting ones to new-style ? They should not be much in the list since those were not updated since a while now, and there was no complain, so i guess most are unused or do not deal with mathematics (e.g. trac, nose, beautifulsoup,...). Ciao, Thierry > > > > On Tuesday, May 12, 2015 at 3:57:47 PM UTC+2, Nathann Cohen wrote: > > > > > That's perhaps a bit problematic at the moment; also, at least some > > > tests may require internet access (although we could tag them > > > accordingly). Should we document/test their versions as well? > > > > Technically, the list of standard packages is available in Sage > > directly (build/install). Maybe we should have a file whose content is > > the list of standard packages (and only that) which build/install > > could then load? > > > > Volker, what do you think? > > > > It seems that all lines in build/install are of the form > > package_name=`newest_version package_name`. Couldn't we generate this > > from the list of packages instead? > > > > > Furthermore, in the "git layout" we only have "new-style" packages > > > (which are currently still a subset of standard+optional), with no > > > differentiation between standard and optional; there, experimental > > > packages (and "the" huge one?) are missing completely AFAIK. > > > > Yep, only those which have been converted into 'new-style' packages > > appear there. Though you can get these lists with: > > sage -standard > > sage -optional > > sage -experimental > > > > All of them require an internet connection. > > > > Nathann > > > > -- > 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. -- 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.
