> > >> We don't have a single MacPort user among a handful of SageMath >>> developers. Please feel free to provide patches. (Yes, it means supporting >>> yet another nonstandard location, more or less, I suppose) >>> >> >> The fun part is that to support Macports, you need to look in >> /opt/local/include for header files, in /opt/local/lib for libraries, >> and in /opt/local/bin for executables. How hard does that sound? >> >> And I daresay, that adding those directories to the Sage config code >> where it is currently looking for stuff, is probably easier for a Sage >> developer unfamiliar with Macports, than for a person experienced with >> Macports that has no clue about Sage guts (and isn't eager to dive into >> those! ;). >> > > the MacPorts-specific part would be to create a list of packages to > install, and put it into build/pkgs/*/distros/macports > and a similar global location. >
I'm not sure I understand what that means. If a package is already installed by Macports - it does not make sense installing it again. More so, Macports keeps a *system-wide* installation, rather than a copy for each user. It might make sense telling Macports to install packages that aren't already installed. But again, I don't see any benefit or even use in something like build/pkgs/*/distros/macports. And, frankly, I see more harm than benefit in Sage getting stuck with copies of packages it builds itself in its private location, becoming bloated and stale at the same time. While the package manager (Macports in this case) keeps track of everything it "owns", shares one copy among all the users, and ensures they're updated. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-support/1f3efa19-cf0a-4db9-9d8e-e0817c8ce5bbn%40googlegroups.com.
