On a related topic, what's the roadmap for the features outside of main ocw folder? Which of those will fold into the main ocw library, which will remain as they are and which will be deprecated?
On Tue, Jan 16, 2018 at 11:33 PM, Goodman, Alexander (398K) < alexander.good...@jpl.nasa.gov> wrote: > Hi Lewis, > > I think that is sort of a hasty action to take. If anything, I question > whether we should even require pydap as a dependency in the first place > since its main advantage (when used as a client-side tool, anyway) is to > provide the ability to load OpenDAP datasets without the netcdf4 library > (which is a core dependency to ocw and pretty much any other earth science > data analysis library out there). In the short term I think we could modify > the conda recipe to drop pydap for python 2.7, as that should fix our CI > problems. > > However in the long term we will have no choice but to drop support for > python 2, as most of the pydata stack (ie, almost all of our core > dependencies) will soon be doing so: > > http://www.python3statement.org/ > > This was actually something I was going to discuss with you and Kyo in my > planned meeting next week, as I have considered releasing the new version > of ocw I am developing as a python 3-only codebase. In terms of our current > dependencies, only esgf-pyclient does not support python 3 (but this should > change soon enough). > > My one concern is that the scientific community in general has been > resistant to switching (don't want to link anything here, since a quick > google search will yield numerous blog posts on the subject). Having > personally been heavily involved in the process of making ocw python 3, I > personally don't blame them since for those users python 3 just adds > needless compatibility issues without offering them a whole lot of > compelling new features. The most recent set of new features for python > 3.x, most notably asyncio (along with the new unicode string model, which > is what actually breaks everything), are of far more use to web developers > than they are to scientists. If it weren't for the fact that the big > projects I mentioned a few paragraphs ago are making a strong push for > python 3, then I am not sure I would even consider it for this project > given our type of userbase. The flipside to this is that as a core > developer, I do understand that maintaining python2/3 support > simultaneously is a rather messy process, and certainly not something I > would be too keen on doing when writing a new codebase in 2018. I'd be fine > with maintaining a python 2.7-only codebase in an ideal world, but > unfortunately that is not the world we are living in so for me personally I > believe there is only one other choice moving forward... > > So yeah, just my 2 cents. Ignoring my rant, here's the tl;dr: I am against > dropping python 2.7 support right away, but would be for gradually phasing > it out (especially if we decide to rewrite the codebase). > > PS: Which reminds me, the "new codebase" I keep mentioning is just a pet > project of mine (currently dubbed "ocw2"), which makes gratuitous use of > pandas and xarray as a data processing backend, rather than vanilla > numpy/scipy. I'll discuss more details and hopefully open source my code > within the next few weeks. > > Thanks, > Alex > > On Tue, Jan 16, 2018 at 7:10 PM, lewis john mcgibbney <lewi...@apache.org> > wrote: > > > Hi Folks, > > You will notice that our TravisCI builds currently report as being > broken. > > This is due to the pydap dependency not being available for Python 2.7. > > Is it time to drop support for Python 2.7 altogether and simplify things? > > Lewis > > > > > > -- > > http://home.apache.org/~lewismc/ > > http://people.apache.org/keys/committer/lewismc > > > > > > -- > Alex Goodman > Data Scientist I > Science Data Modeling and Computing (398K) > Jet Propulsion Laboratory > California Institute of Technology > Tel: +1-818-354-6012 >
