Change QIIME to Qiita [AKA Travis' playground]

[ElDeveloper]

No description provided.

[adamrp]

I think the Travis error message indicates that in order to pip install cogent, we need sphinx. I assume this should be added to setup.py? Or is this really a problem with cogent...?

[ElDeveloper]

No, I think the problem is that as it is Qiita cannot support python 3.2 because it depends on other packages that do not support it. This is something that should be changed in the .travis.yml file.

[antgonza]

I guess this is where we gonna have that talk! There are a few options
here: have travis test using python 2.7 and 3.2, only 3.2, only 2.7. What
do we want?

[adamrp]

Assuming we can do both in less than the 50 minutes allotted, I think we
should.

On Wed, Feb 19, 2014 at 11:19 AM, Antonio Gonzalez <[email protected]

wrote:

I guess this is where we gonna have that talk! There are a few options
here: have travis test using python 2.7 and 3.2, only 3.2, only 2.7. What
do we want?

Reply to this email directly or view it on GitHubhttps://github.com//pull/25#issuecomment-35530174
.

[josenavas]

We can try to do both, at some point cogent is not going to be a dependency and QIIME will hopefully be 3.2 compatible...

[ElDeveloper]

Given that we don't have any explicit support for 3.x we shouldn't be testing it right now, but we should in the future. Otherwise all of our tests are going to fail, in order to fix this we would need to: QIIME, pyqi, bipy, cogent, emperor and all of the packages that come installed as consequence of the dependencies be 3.x compatible. That's an awful lot of work ...

[josenavas]

👍 until all our dependencies are 3.x compatible

[adamrp]

Sounds good -- but we may want to make development on some of these
dependencies a goal at a code sprint in the not-too-distant future, since
many of us develop many of these packages... I'm fine with not testing on
3.x for the time being, just as long as we are aware that we are
effectively passing the buck to our future selves...

On Wed, Feb 19, 2014 at 11:25 AM, josenavas [email protected]:

[image: 👍] until all our dependencies are 3.x compatible

Reply to this email directly or view it on GitHubhttps://github.com//pull/25#issuecomment-35530784
.

[ElDeveloper]

Our future selves are wise and full of joy, they'll take care of this in no time.

[josenavas]

Well, if we think that other projects are blocking the development of Qiita, then we should spend the code sprints in this other projects...

[adamrp]

They're not blocking per se, but we have been talking about Python 3
in a variety of projects for a long time, and support was originally a
design goal for Qiita. I think we should not spend the Qiita code sprints
developing other projects right now (there's still a lot to do on the
basics of Qiita).

As seems to be our custom, let's table python 3 discussion for the time
being, but recognize that we are either lying to ourselves about plans for
Python 3 support, or that we are currently adding to the heap of Python
3-related tasks we have already compiled.

On Wed, Feb 19, 2014 at 11:31 AM, josenavas [email protected]:

Well, if we think that other projects are blocking the development of
Qiita, then we should spend the code sprints in this other projects...

Reply to this email directly or view it on GitHubhttps://github.com//pull/25#issuecomment-35531412
.

[josenavas]

We should make sure that our Qiita base code is Python 3 compatible (during code reviews), so that the only thing that is not making Qiita Python 3 compatible are the dependencies. Once they are fixed, Qiita will become Py3 compatible...

[ElDeveloper]

👍

On Feb 19, 2014, at 11:46 AM, josenavas [email protected] wrote:

We should make sure that our Qiita base code is Python 3 compatible (during code reviews), so that the only thing that is not making Qiita Python 3 compatible are the dependencies. Once they are fixed, Qiita will become Py3 compatible...

—
Reply to this email directly or view it on GitHub.

[adamrp]

I'm not sure that's actually possible (to have Qiita python 3 compatible, but at the same time allow for dependencies to be only python 2 compatible); check out the question on this page called "I want to use Python 3, but there's this tiny library I want to use that's Python 2.x only. Do I really have to revert to using Python 2 or give up on using that library?"

I guess we could write it in 3, so that we know it works, then use the 3to2 tool to back-convert it, and store both versions of the code in the repo? This seems messy, though.

[josenavas]

I like the first solution:

Port the library to 3.x.

😆🍻🍻

[adamrp]

@josenavas lol I know, right!? Ah well. My position on this whole thing is "I personally don't care about Python 3, but if we say that we are going to do it, we should be realistic about it." It seems that at this time, being realistic about it (which entails understanding exactly what it would take to actually do it) means that we shouldn't do mess with Python 3 right now. So let's just move forward with Python 2.7, unless anyone else has something to add.

[ElDeveloper]

[wasade]

@josenavas @adamrp suggest at least py3 compat constructs (e.g, ValueError("foo")). we'll never actually get to the upstream version of python if none of our packages commit to making compatible code

[josenavas]

👍

[adamrp]

Cool, yeah, we should definitely do that as much as possible

On Wed, Feb 19, 2014 at 3:24 PM, josenavas [email protected] wrote:

[image: 👍]

Reply to this email directly or view it on GitHubhttps://github.com//pull/25#issuecomment-35557379
.