PyCon is going on right now in Portland. One of the talks today was about
how IPython managed dropping support for python2 in IPython 6.0. You can
watch the talk here:
Some takeaways from me (all opinions my own):
IPython probably did this a bit too early. Since they're relying on
features in pip and setuptools that were only added a few months ago, users
are unlikely to have up-to-date versions that will behave nicely.
On the other hand, IPython is a big enough package that they are actually
driving people to update their pip installation after hitting some breakage.
We can do things now to minimize pain in the future if we do drop support
for some python versions we support right now:
* Define requires_python in our setup.py
* Update our documentation and scripts to use "pip install ." or "pip
install -e ." instead of "python setup.py install" or "develop"
We've come up with a final list of issues that will block the release of yt
If you know of any issues that you think should be addressed before we
release yt 3.4, please speak up.
If you are interested in working on any of these issues, please feel free.
If someone has already assigned it to themselves you may want to check with
them first. If no one has been assigned an issue you're interested in
fixing, feel free to issue a pull request for it.
Hopefully we'll be able to get yt 3.4 out soon :)
Britton and I have scheduled a hangout for Wednesday at 3:00 PM central
time to triage the issue list for yt in preparation for shipping yt 3.4. If
you'd like to join in let me know and I'll send you an invite to the event.
Optimally we'll end this hangout with a more manageable list of issues that
block the release of yt 3.4 than the current list of 94 open issues.
I've just enabled continuous integration via Appveyor for yt-project/yt.
This will allow us to continually test that yt is working on windows.
Please let me know if you run into issues relayed to the Appveyor testing.
I have a couple of announcements regarding the current testing
infrastructure that's integrated with GitHub:
* if for some mysterious reason the test suite fails, and you're pretty
sure it's not due to the incoming changes, you can trigger another build
by adding a '@yt-fido test this please' comment on your PR.
* docs builds for PRs are now disabled. We are blocked by:
Development version of docs is built and deployed just fine.
As usual, if you notice something not working, please let us know.
Now that we're fully on github I took the opportunity today to triage our
issue list. There were a number of issues that I could close immediately
either because they are fixed already, were classified incorrectly as open
when we imported them from bitbucket, or because there wasn't sufficient
information to reproduce or understand the reported issue.
That leaves us with 97 open issues. Now we need to decide which of those 97
issues should be blockers for a 3.4 release. Currently almost all of the
open issues are in a new 3.4 "milestone" we can track:
I've also created a bunch of labels. We can probably bikeshed about what
they should be named and if we have too many:
I'd like to propose that we move all the issues I've marked "new feature",
"help wanted", and "wish" labels to a new 3.5 milestone. In addition, I
think many of the issues marked "enhancement" can also be moved.
I think it would be worthwhile to schedule a hangout sometime in the next
couple weeks to determine which issues should block a 3.4 release. Let me
know if you are interested in that so we can figure out a date and time.
We just merged our first pull requests on github! We wanted to wait on
doing this until the mirror bot was updated, which is now complete. If you
have a commit bit, you should feel free to merge PRs that have undergone
sufficient review. You can also indicate that you reviewed and approved a
PR by either commenting on it or by going through the github code review
interface (see https://help.github.com/articles/about-pull-request-reviews/
Thanks very much to everyone who helped out with this effort! So far I
think it's been pretty painless (*knocks on wood*). That said, please let
us know if you run into any issues (e.g. with yt setups that use a source
install of yt from a mercurial repo).
Now that yt development has moved to github, I want to bring up an
opportunity for some smaller yt-related development projects.
As some of you may know, it was decided a couple months ago that most of
the code in the analysis_modules directory will be moved to various
external repositories to allow them to be developed separately from the
main yt codebase. The rough timeline for this is to have all analysis
modules marked as deprecated by the release of yt-3.4 and fully removed
(and in a separate, pip-installable repo) by yt-4.0.
The initial extraction of the analysis modules has now been done and can be
To be clear, the analysis modules are still present in yt, but this repo
contains only those modules. The revision history has also been
maintained. Anyway, there are a number of small tasks that must be
completed before this package becomes the replacement for yt's analysis
modules. I will begin adding issues on github for all these. If anyone is
interested in helping out with this, just come talk to me on the yt slack
channel or feel free to just dig in and start issuing PRs.
For those of you who are "members" of the project on GitHub, if you are
willing, please mark your status as "public." You do this by going to:
finding your name, and then clicking the dropdown where it says "Private"
and choosing "Public".
I'm ok with porting my pull requests over, but I'd really like it if we
could merge in the pull requests from Weiguang Cui:
https://bitbucket.org/yt_analysis/yt/pull-requests/2534 (Gadget I/O
https://bitbucket.org/yt_analysis/yt/pull-requests/2560 (docs for PR 2534)
and Andrew Myers:
https://bitbucket.org/yt_analysis/yt/pull-requests/2575 (support for
face-centered fields in the AMRex frontend)
I realize that both of these PRs are quite frontend-specific and that not
everyone will feel comfortable reviewing, but it would be helpful if you
could step out of your comfort zone and give it a shot. I'm personally of
the opinion that both of these efforts are mergeable as-is.
If others feel that we shouldn't rush these through that's ok, I'm just
worried about these in particular because they've been open for a while and
haven't seen sufficient code review.