On Tue, 15 Jan 2013 08:32:29 -0800 (PST) Timo Kluck <tkl...@gmail.com> wrote:
> Op dinsdag 15 januari 2013 17:01:09 UTC+1 schreef Burcin Erocal het > volgende: > > Why don't we discuss the solutions to these problems > > separately and put them into action? > > > > - Development model: > > > > I like the idea of keeping a branch for each issue on Trac. > > > > With a student, I even set up a patched roundup install with > > this feature. I can enable it on the lmonade issue tracker if > > anybody is interested in testing this out. Though I believe using > > gitlab and not reinventing the wheel is far better. > > > You may have seen that I set up a testing server for gitlab with a > couple of branches imported into git from trac. (see > http://vps805.directvps.nl) Unfortunately, the issue management in > Gitlab is rather primitive and they don't really want to make that > any better. From my perspective, the most viable option is to keep on > using trac, and set up a Gitlab server specifically for managing > access to the git repository and for discussing pull requests. I'm > not sure what advantages a Gitlab server will have over just using > Github in that case, though. I didn't try your gitlab setup. I only know about it from reading the sage-git@ list. If git does not come with a killer-app to solve the development model problem, I don't see the motivation to switch to git. AFAIK, we don't want to use github. If we are going to write a trac plugin to manage a branch per ticket, or something similar, this can also be written for a mercurial backend. Karl-Dieter pointed this out before, but let's reiterate: Switching to git will mean rewriting all hg_* functionality and the developer guide, as well as retraining many existing user/developers. > > - Build system > > > > This actually has two items: > > > > - integrating the repositories > > > > Why? > > > > AFAICT, the only reason is to allow us to specify the > > dependencies of the Sage library better. ATM, when a patch goes > > into Sage, the corresponding patch to update the spkg is in a > > separate repository. Putting these together would help coordinate > > the two. > > > > Do we really need to coordinate these? Why is Sage any > > different from any other large software package out there? > > > > The standard solution to this problem is to add a "configure" > > script to the library which checks if the dependencies are > > satisfied and sets various options for the compilation process > > accordingly. > > > > The initial design of Sage separated the mathematics library > > from the distribution system, then further separated the user > > interface (notebook) from the mathematics library. Why are we now > > trying to reconcile a bunch of shell scripts with a Python/Cython > > library for mathematics? > > > I think the main reason is that Sage currently tries to be both a > package manager and a mathematics library. I guess in a way, it would > make sense to have 2 repositories: > > * the sage library > * the package manager > > The 4 that we have now is too much, though. Yep, ATM there are too many repositories. I find this amusing: sage: hg_ hg_extcode hg_root hg_sage hg_sagenb hg_scripts Life was easier in the early days, when there were only two repositories that mattered, Sage library and scripts. Thinking about it, even then there were a lot of confusions. > But it is pretty clear that the package manager will depend so much > on the sage library I don't see why. Do you need computational algebra to compute dependency trees and drive a couple of shell scripts? ATM, the scripts in spkg/ don't rely on the library at all. The package database and the versions may depend on changes in the Sage library. This information might as well be included in the library, through a configure script, or a recipe file for a package manager, like a gentoo ebuild, nix expression, etc. > But I think it would be nice for the two parts to be at least > separable enough that it is possible to release a tarball for just > the sage library. +1 This would also simplify lives of people packaging Sage for distributions. > > - rewriting the build system > > > > I agree that things can be done much better, but I don't > > understand why there is talk of rewriting. There are plenty of > > excellent package managers around. Why not just use one of > > them? > > > > I looked into this, seeing whether we could use portage, pkgsrc, apt > or macports for this. Unfortunately, they all either require root > privileges and/or a dedicated user added to the system (portage, > apt), require you to have the entire dependency tree (pkgsrc), or > rely on mac-specific libraries (macports). There are a few alternatives that run as a regular user. Gentoo Prefix, Nix, and maybe GoboLinux come to mind. > Technically, the macports system is actually really nice: each > 'portfile' contains a list of dependencies, a url for the tarball, > and can optionally specify/override configure/make/install steps. It > may be possible to isolate the right Tcl scripts from the macports > package to turn it into a compatible package manager for us. IMHO, this is more or less the same for all package managers. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
