Re: [yt-dev] Future of the install script

16 Jan 2016


      I think combining the two scripts into a single script is still the best
way to go.  For a new user, it will be confusing which they should use
between "get_yt.sh" and "install_script.sh".  If this is not feasible, then
we can rethink it.

On Fri, Jan 15, 2016 at 6:37 AM, Nathan Goldbaum 
wrote:
...
On Friday, January 15, 2016, Matthew Turk  wrote:
...
Okay -- my reluctance (which is all it was!) in the original email to
combine the two scripts was because I didn't think it was feasible,
but I could be wrong.  Do we want to prioritize this before a 3.3
release, which is already crammed full of stuff?
I'd like to give it a try, our installation story is pretty bad right now
with the rampant SSL issues.
...
...
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 
wrote:
...
On Friday, January 15, 2016, Matthew Turk 
wrote:
...
...
Hi Nathan,
On Fri, Jan 15, 2016 at 7:52 AM, Nathan Goldbaum <
nathan12343@gmail.com>
...
wrote:
...
I've changed the subject line to avoid derailing the other thread.
On Friday, January 15, 2016, Matthew Turk 
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
> 
> wrote:
> >
> >
> > On Thu, Jan 14, 2016 at 1:45 PM, Andrew Myers <
atmyers2@gmail.com>
...
...
> > wrote:
> >>
> >> Dear yt developers,
> >>
> >> yt version 3.2 was released back in July of 2014. Since then,
On Fri, Jan 15, 2016 at 8:18 AM, Britton Smith 
wrote:
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@lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>
> >
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev@lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- 
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
http://chummels.org

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org