[yt-dev] Future of the install script

Britton Smith brittonsmith at gmail.com
Fri Jan 15 06:18:02 PST 2016


I think I'm also in favor of having one script, if it's possible.  This is
especially true if the two options are named install_script.sh and
get_yt.sh.

On Fri, Jan 15, 2016 at 2:01 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Friday, January 15, 2016, Matthew Turk <matthewturk at gmail.com> wrote:
>
>> Hi Nathan,
>>
>> On Fri, Jan 15, 2016 at 7:52 AM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> > I've changed the subject line to avoid derailing the other thread.
>> >
>> > On Friday, January 15, 2016, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>> >>
>> >> Hi Nathan,
>> >>
>> >> (I'll reply to Andrew a bit later once I've thought it over.)
>> >>
>> >> I'd strongly campaign against unifying the two scripts right now, if
>> >> ever.  I don't like that we have two either, but I don't think we
>> >> should make this part of the 3.3 release cycle, just because it's yet
>> >> another major potential disruption.  It would be nice to work out a
>> >> way to migrate nicely to conda, but maybe we should hold off until we
>> >> have infrastructure in place for our own conda package builds?
>> >
>> >
>> >
>> >
>> > What do we do about people who want to install on the latest versions of
>> > OSX? What about clusters that have older SSL installs?  Right now our
>> > solution is to tell people about get_yt.sh when they complain on the
>> mailing
>> > list, but I wouldn't be surprised if we're missing people who give up
>> after
>> > getting errors.
>>
>> SSL and OSX are the two biggest problems, which does not exclude the
>> full gamut of places that the install script works.  Perhaps I am
>> being myopic in suggesting we not deprecate the install script.
>
>
> My idea was not to deprecate the install script, but to combine it with
> get_yt.sh. My ideas is that users would be able to choose at install time
> whether they want a source install of dependencies or binary from Conda.
>
>
>>
>> >
>> > Why do we need our own package builds?
>>
>> Nightly builds of yt is what I was referring to.
>
>
> This already happens, FWIW.
>
>
>>
>> >
>> > What about simply linking to get_yt.sh on the website?
>>
>> I thought we did this?  I thought I added it at some point.  I'm in
>> favor of this, and even putting it above the install_script.
>
>
> Nope, not yet. The last time I suggested this Cameron objected that it was
> bad UX and a bit confusing.
>
>
>>
>> >
>> >>
>> >>
>> >> On Thu, Jan 14, 2016 at 5:20 PM, Nathan Goldbaum <
>> nathan12343 at gmail.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Thu, Jan 14, 2016 at 1:45 PM, Andrew Myers <atmyers2 at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Dear yt developers,
>> >> >>
>> >> >> yt version 3.2 was released back in July of 2014. Since then, there
>> >> >> have a
>> >> >> been a number of cool new features added (good work, everyone!),
>> and it
>> >> >> would be nice to get them into a stable release. However, there are
>> a
>> >> >> few
>> >> >> major things that need to be done before that can happen. First,
>> there
>> >> >> are a
>> >> >> number of outstanding issues related to the volume render refactor
>> that
>> >> >> need
>> >> >> to be addressed before 3.3 can be released. Additionally, version
>> 3.3
>> >> >> will
>> >> >> include unstructured mesh visualization support, and there is some
>> more
>> >> >> work
>> >> >> Matt and I need to do before that is ready. Other than those things,
>> >> >> though,
>> >> >> is there anything I'm leaving out that people want to get in before
>> >> >> version
>> >> >> 3.3 is released?
>> >> >
>> >> >
>> >> > I would like to see the install script situation resolved. In
>> >> > particular, I
>> >> > think get_yt.sh and install_script.sh should be merged, and users
>> >> > should be able to choose at install time whether or not they want a
>> >> > source-based install or a miniconda-based install.
>> >> >
>> >> >>
>> >> >>
>> >> >> Thanks for your time,
>> >> >> Andrew
>> >> >>
>> >> >> _______________________________________________
>> >> >> yt-dev mailing list
>> >> >> yt-dev at lists.spacepope.org
>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > yt-dev mailing list
>> >> > yt-dev at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160115/a24ba87f/attachment.html>
-------------- next part --------------
_______________________________________________
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