[Yt-dev] [yt-users] install problems
gso at physics.ucsd.edu
gso at physics.ucsd.edu
Mon Mar 14 17:59:59 PDT 2011
> Thoughts, from OSX users? Britton, Stephen, Rick, Cameron, Tom,
> Brian, everybody? (Are Jeff and I the only ones who don't use OSX
> anymore?)
OSX user here,
I just think it is a safer route to avoid sudo and using system python as
long as the python provided can be build with gcc which everybody have.
Whenever I use sudo to install something I'm afraid that I might break
something that I won't know how to fix later. So I think it's better to
have a unified install script that works everywhere instead of many
scripts that work only on one particular OS, easier to manage too!
my 2c
From
G.S.
> Hi Britton and Stephen,
>
> Sorry for the delay in replying, as I was away for the weekend. I did
> have a chance to think over a number of these issues, which I want to
> address.
>
> On Sat, Mar 12, 2011 at 1:22 PM, Stephen Skory <stephenskory at yahoo.com>
> wrote:
>> Matt & Britton,
>>
>>>OS 10.6 comes with python 2.6. Would it be better if they just used
>>> that python and didn't try to build another one? Can we add another
>>> flag to the install script to optionally build python?
>>
>>
>> Along the same lines, we could write some instructions on using yt with
>> enthought python. It comes with many handy things...
>
> Well, there are a couple things in here. I'm not sure Enthought's
> goals align with ours is the first and primary one. However, the more
> pragmatic one that I can put my finger on is that I don't think that
> the EPD provides an HDF5 library that we can both *identify* and link
> against, and certainly it does not provide one that can be used by
> Enzo. Other than the issue of HDF5, this solution would work. If you
> can verify that yt and Enzo can (find and) build against the Enthought
> HDF5, this would probably be okay. I added a few checks to the yt
> build procedure to try to identify the correct HDF5. (Note that
> because Enthought provides framework builds it's a .dylib.
>
>>
>>>>>>Can you check the options in ./configure, and if none of those are
>>
>> There is no preference for that in ./configure AFAICT.
>
> I see --without-included-gettext, but I believe that might just be
> autotools cruft.
>
>>
>>>>>>obvious, can you investigate how much work getting a localize gettext
>>>>>>to install is?
>>
>> I installed gettext - it didn't help.
>
> Okay.
>
>>
>>> Or, better yet, maybe this is improved/fixed in python
>>>>>>2.7, and you could test that?
>>
>>
>> I might try that out.
>>
>
> My guess now is that it won't. I think the issue is simply an issue
> of a broken gettext install coming from something else like ports or
> fink or homebrew or who knows what. It would also not surprise me if
> the Apple compiler -- which has a history of "helpfully" adding
> #include statements, non-intuitively linking against .dylibs/.sos that
> are incorrect and generally not being as helpful as it thinks it is --
> is doing something unhelpful.
>
> Here's the chain of events as I see them:
>
> 0) The user has installed something that also installs a gettext
> without the correct set of symbols in libintl.
> 1) The user attempts to install Python (2.6)
> 2) The _locale module, which acts as the C-bridge for gettext to
> python, fails to compile
> 3) Later on, another module (hg in this case) attempts to import
> _locale and fails
>
> Looking over the Python 2.7.1 codebase, it appears that they have made
> a number of changes to the _localemodule.c source that are consistent
> with fixing this bug. Could you give it a shot? I have uploaded a
> new install script here:
>
> http://yt.enzotools.org/files/27_install_script.txt
>
> (Server issues for the file extension.)
>
> So as to Britton's suggestions, I wanted to start out with my broad
> feelings and a brief delving into not-too-distant-history.
>
> I think if we don't provide an installation script for OSX, people
> simply won't install and use it. This is how it used to be; back in
> the day, it was basically impossible to get yt running anywhere.
> (Anybody remember when a tertiary dependency required boost 1.31.1,
> but not any other version? Yowza.)
>
> We used to provide not an installation script, but a bunch of binaries
> I built myself that were included in a script. These were all linked
> against a "Framework" build of Python. This became much, much harder
> to keep up to date with OSX 10.6, because of the mixed mode
> compilation for 64-bit/32-bit. It got to the point where it was
> unmaintainable, and on the suggestion of some people here (I think
> Rick, actually, was the one who suggested it? Maybe?) we moved to
> trying to provide a unified installation script which did *not*
> attempt to provide framework builds. The utility of a framework build
> is much less when you don't use GUIs, so a single, isolated stack
> seemed to work better, and to be much less intrusive. It also didn't
> require sudo.
>
> So if we were to return to not providing a Python but using the system
> Python, there are some upsides and downsides. The (apparent) upside
> is that things would work better. (I am skeptical.) But, we would
> then have to provide one of the following things:
>
> 1) A from-source build that installed the dependencies (Apple provides
> a broken NumPy) using sudo into a systemwide framework build location
> 2) A from-source build that utilized the per-user site-packages
> directory provided by distutils; this means that all the packages
> would live under a home directory, but executables would not be
> installed
> 3) A set of links to manual installation of binary builds of some
> things and source builds of other things.
>
> I think the first two are difficult. The third one is easier for us,
> but much, much harder for other people to do -- go through the steps,
> install in the right order, mix between GUI/CLI. I think the best
> option is to fix it. And I think 2.7 might fix it. I really, really
> don't want to go back to forcing people to install everything
> manually; too much of our userbase is on OSX 10.6. And while I think
> if we get around a few of the oddities of linking on OSX (which is
> probably unavoidable, considering how hostile to non-iOS developers
> Apple is becoming) we can provide this unified stack.
>
> Plus, I think there are a lot of interesting things we can leverage
> the install stack to provide, and I'm not really sure we should give
> up on it yet.
>
> Thoughts, from OSX users? Britton, Stephen, Rick, Cameron, Tom,
> Brian, everybody? (Are Jeff and I the only ones who don't use OSX
> anymore?)
>
> -Matt
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
More information about the yt-dev
mailing list