You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@climate.apache.org by "Goodman, Alexander (398K)" <al...@jpl.nasa.gov> on 2016/11/28 22:55:48 UTC

Re: Preparatory work for 1.2.0 Release

Hi Lewis,

I think at this point we are ready to make a 1.2.0 release. Are you able to
set this in motion?

Thanks,
Alex

On Wed, Oct 19, 2016 at 11:02 PM, Goodman, Alexander (398K) <
alexander.goodman@jpl.nasa.gov> wrote:

> Hi Lewis,
>
> All good points. The reason I initially thought it would be good to put an
> rc on conda-forge would be to make it easy to process the dependencies for
> all python versions in travis.yml. However this is not a feasible option
> now that you mentioned that you can only put an rc on PyPI's test site, but
> the conda recipe gets the source distribution from the main site.
>
> Fortunately I have found some alternatives since I wrote my last response
> I have investigated some better ways to integrate conda with travis CI
> while building for different python versions. For now I think the approach
> we should use is to have two separate text files listing dependencies, one
> each for Python 2 and 3. Of course it would be easier if we had the full
> recipe due to the ability to manage dependencies with preprocessing
> selectors (eg, specify in the comments of the recipe to ignore dependency X
> if it isn't python 3 compatible), but we can always change this in the
> future.
>
> For python 3 compatability, the current offending packages are pydap
> (which you are addressing separately) and esgf-pyclient / myproxyclient.
> The maintainer of the latter project has been responsive as far as my
> previous interactions have been concerned, so I think I'll see what I can
> do as far as getting it working with python 3. This probably can't be done
> in time for 1.2.0, but we can always update the conda recipes for those
> three packages on conda-forge separately.
>
> So tl;dr, I think it should be feasible to resolve CLIMATE-874 (and
> therefore, the CI issues) by the end of the week, and update the conda
> recipe from 1.1.0 to 1.2.0 only when we are ready to release it. Does this
> sound good?
>
> Thanks,
> Alex
>
> On Wed, Oct 19, 2016 at 9:35 PM, lewis john mcgibbney <le...@apache.org>
> wrote:
>
>> Hi Alex,
>> Responses inline
>>
>> On Wed, Oct 19, 2016 at 6:31 PM, <de...@climate.apache.org>
>> wrote:
>>
>> >
>> > From: "Goodman, Alexander (398K)" <al...@jpl.nasa.gov>
>> > To: "dev@climate.apache.org" <de...@climate.apache.org>
>> > Cc:
>> > Date: Wed, 19 Oct 2016 18:25:35 -0700
>> > Subject: Re: Preparatory work for 1.2.0 Release
>> > Also, one thing I would like to add is that the dependency issues we are
>> > seeing with the CI tests have been happening since this commit
>> >
>> > https://github.com/apache/climate/commit/98020c9fe7654267d03
>> > f8553f35af4ca9ed55952
>> >
>>
>> Good catch!
>>
>>
>> >
>> > Based on the raw logs from the CI tests, it seems like the dependencies
>> are
>> > being downloaded but setuptools can't find them. We could revert this
>> > commit but that would be pointless anyway since we now also want to test
>> > for Python 3.x.
>>
>>
>> Yeah. I think that having CI 'unstable' for now is a reasonable temporary
>> sacrifice for us actually fixing the issue.
>>
>>
>> > Thus, solving this issue may be tied to CLIMATE-879 (put
>> > the conda recipe on conda-forge) and CLIMATE -874 (Remove Easy OCW and
>> > replace with a pure conda installation method).
>>
>>
>> All have been remarked for 1.2.0.
>>
>>
>> > Only thing to keep in mind
>> > is that if we go down this route, we won't be able to have a fully
>> > functional CI test-suite for Python 3.x until AFTER the 1.2.0 package is
>> > uploaded.
>>
>>
>> I just woke up... can you expand a bit? Why is this the case?
>
>
>> > Thus, I think we will need to do before officially releasing
>> > 1.2.0:
>> >
>> > 1) Get 1.1.0 on conda-forge [0]
>> > 2) Make ocw compatible with podaacpy 1.4.0 [1]
>> >
>>
>> Both of the above seem fine.
>>
>>
>> > 3) Put 1.2.0 release candidate on PyPI AND THEN conda-forge
>> >
>>
>> This is a bit tricky, the reason I say is that we can put a release
>> candidate into test.pypi.org but not on to pypi.org. The former is fine,
>> the latter would constitute a release... which is not what we are trying
>> to
>> do unless we are actually releasing.
>>
>>
>> > 4) Update CI testing to download all packages via conda and fully
>> > deprecating Easy-OCW
>> >
>>
>> ack, however could this not be done prior to releasing 1.2.0?
>>
>>
>> > 5) If resolved, we are ready to release
>> >
>> > [0] https://github.com/conda-forge/staged-recipes/pull/1784
>> > [1] https://github.com/apache/climate/pull/411
>> >
>> > What do you think?
>> >
>> >
>>
>
>
>
> --
> Alex Goodman
> Data Scientist I
> Science Data Modeling and Computing (398K)
> Jet Propulsion Laboratory
> California Institute of Technology
> Tel: +1-818-354-6012
>



-- 
Alex Goodman
Data Scientist I
Science Data Modeling and Computing (398K)
Jet Propulsion Laboratory
California Institute of Technology
Tel: +1-818-354-6012