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
