Hi ObsPy-list,
first of all I must admit that I am not sure if this is the right channel to address my problem. So if there is a more appropriate way (e.g. more specific list, issuing one/several ticket), please point me to it.
MacPorts
I was not particularly happy with the options for installing ObsPy on the Mac. Therefore, I created a set of Macports (http://www.macports.org/) which is my preferred way to manage software on the Mac. As it works quite fine for me (with one important exception, see below), I am considering to contribute these port, hoping (if it is accepted) that it might be useful to a larger community. Similarly to the FreeBSD ports, for each packages (as available at PyPI) a port is created, a metaport should help to install a useful (sub)set of the ObsPy framework.
However, this rises some issues I ran into and which I would like to discuss here:
- port descriptions
- ObsPy metaport
- obspy.taup building problems
(1) Port descriptions
In order to be meaning full in the context of the MacPorts system (eg. port search, port info), I had to edit the descriptions of the packages slightly. I would appreciate if someone would take the time to check weather you still fine with these edited description and provide feedback, before I procede.
Attached you find the descriptions:
- single line description
- port specific description
- general description of the framework
ports.list (1.76 KB)
ports.desc_comp (4.67 KB)
ports.desc_obspy (755 Bytes)
Hi Petr,
thanks a lot for all your effort! It is most appreciated.
Using the mailing list for this discussion is fine I guess.
I am not really familiar with MacPorts as I usually use Homebrew for this kind of purposes but I believe both work in a similar fashion. When I originally created the ObsPy OSX installer/application/whatever else you want to call it, I considered using one of these package managers. I then decided against it because Homebrew (and to my understanding also MacPorts) does not distribute binary files and thus requires a compiler. This usually means that the user has to get Xcode for the developer tools. This is not really a problem (except that for more recent versions in which the developer tools have to be installed separately from within Xcode) but it takes a long time and our goal was to have the user up and running with ObsPy as fast as possible. The application (together with virtual environments) works just fine and is very easy to install but I do also see the appeal of using a package manager and would be happy to assist you.
ObsPy itself does not, and never had, a version number and was fully modular from the beginning. This unfortunately also has some drawbacks and, to our experience, most users just install all ObsPy modules anyway. We are currently considering changing the architecture into one large codebase. This, among others, would solve the versioning problem and also make the installation more intuitive. I would therefore advise you to give us some weeks (I think it should be done by mid august) before you continue working on your ports.
The obspy.taup building problem in essence boils down to the issue you described about the system gcc not being aware of the separately installed gfortran. Actually the only problem is that gcc cannot find libgfortran for the final linking step. I don't think that this influences portability (at least on Linux distros - we don't officially support anything else and Windows is different anyways) to a large degree because any sane system would always make sure that the gcc tools can find the Fortran libraries. I don't believe OSX will ever ship with Fortran. There is simply no incentive for Apple to do so. They are even slowly moving away from gcc towards LLVM and clang.
A simple fix for your case would be to simply add the path containing the correct libgfortran version to the LD_LIBRARY environment variable right before installing obspy.taup. I guess this should be possible from within a port.
Nevertheless it has been a problem for a while and it should be fixed. The only "clean" solution I can think of would be to use gfortran also for the linking. Why should this not be portable? Portable in the sense that it works with the gnu toolchain. But this in turn requires a hack to distutils… I'll look into it as soon as I find some time. If in the meantime you find a good solution let us know.
In any case I would strongly suggest (even if we do not end up moving to a non-modular architecture) to only offer the "full" variant. No need to offer many different variants when most people will simply install everything.
But as I said, please give us some time for the architectural changes we plan to implement.
By the way: Is there any specific reason why you chose MacPorts over Homebrew?
Best wishes,
Lion