Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This
site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early
summer, and then aiming for a yt 4.0 sometime about six months later. yt
4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly
supports python 2, and then to "softly" drop support for python 2 during
the cycle for yt 4.1, which would be about six months later, we
anticipate. This would mean not testing on py2 anymore and potentially
removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I
wanted to put it out there. I personally support this proposal.
-Matt
Hi folks,
Here is the process I just used for exporting a pull request to GitHub. It
went incredibly smoothly. I will put this in a migration document as well.
Step 0: Make sure you have hg-git installed (it is pip installable) and
enabled in your ~/.hgrc . Enabling it looks like this:
[extensions]
hggit=
Now, here are the steps:
1. Fork http://github.com/yt-project/yt
2. In your yt source repository, update to the latest changeset of your
pull request.
3. If it does not have a bookmark, create one with "hg bookmark". It can
be something like "hg bookmark whatever_i_want_to_call_it"
4. Edit your .hg/hgrc in your yt repository. Under [paths] add a github
one. For me, it looks like this:
[paths]
default = ssh://hg@bitbucket.org/MatthewTurk/yt
ytanalysis = ssh://hg@bitbucket.org/yt_analysis/yt
gh = git@github.com:MatthewTurk/yt
ghyt = git@github.com:yt-project/yt
You will need to modify `gh` here.
5. Now, check what you're going to export. "hg outgoing -r
whatever_i_want_to_call_it gh" will show you. Make sure that this matches
what you anticipate.
6. If it all looks good, push it *with the bookmark*. "hg push -B
whatever_i_want_to_call_it gh" will do this.
7. Reopen the pull request on GitHub, and decline your pull request on
BitBucket.
Here is the one I just did: https://github.com/yt-project/yt/pull/1346
This should make things very smooth to transition. Since we're not yet
*accepting* things on GitHub, I would encourage folks to start moving their
long-term PRs. (does that sound right, Nathan and Kacper?)
-Matt
Hi folks,
I wanted to share this article about IPython 6. I thought it really
thoughtfully talked through the Py2 sunset procedure they're using, and I
think it is good fodder for us to think about as we figure out our Py2
sunset procedure as well.
https://blog.jupyter.org/2017/04/19/release-of-ipython-6-0/
Matt
Hi all,
I think the github mirror we set up for testing purposes has been more or
less a success:
https://github.com/yt-project/yt-test
The mirroring seems to work well: the github repository is staying in sync
with the bitbucket repo every time we merge pull requests on bitbucket. To
make further work on transitioning to github easier, I'd like to settle on
what the final converted repo should like.
For the purposes of discussion, I'd like to propose simply renaming the
yt-project/yt-test repo to be yt-project/yt and agreeing that the current
conversion is satisfactory. This means we'll agree not to use an alternate
conversion technique that will change git commit hashes.
Our mirror bot uses hg-git, and the converted repo hg-git produces isn't
necessarily perfect. In particular, two issues have come up:
* Since git is more selective than mercurial about e-mail and username
formatting, there are a number of commits associated with dummy e-mail
addresses like none@none
* Since we do most of our development on a branch named "yt" (not "default"
as is typical of mercurial repos) almost every commit in our history has a
comment in the git commit message recording that it hapenned on the "yt" or
"stable" branch. This makes it possible to round-trip from hg to git and
back to hg, but it's also some extra noise in every single commit message.
We could in principle ameliorate these issues by using something besides
hg-git to do the conversion or by modifying hg-git to avoid these issues.
The former options will lose the nice property of being able to round-trip
and for others to independently export work from their forks. The latter
option will require us to modify hg-git and waiting for upstream hg-git to
review our changes, which might take a while, or telling everyone to use a
hacked version of hg-git.
Personally, I don't think either of those options are worth the hassle for
what to me are minor annoyances. I think I've also ameliorated the
username/e-mail ambiguity in the converted history by adding a .mailmap
file to the repo:
https://bitbucket.org/yt_analysis/yt/pull-requests/2582
In addition, the mirroring process we have now seems to work well, so just
renaming the yt-test repo and calling the conversion final avoids a bunch
more work which will block further progress on the conversion.
What do you all think? It would be great to get people's +/-1 on renaming
yt-test to yt on github.com/yt-project.
Once we have a final repo name we will be able to start porting tooling
like the website generator without worrying about the name or content of
the final repo changing.
-Nathan
Hi folks,
We're making good progress on the migration to GitHub.
I'd like to put out a call to ask for help with a few things. The list of
outstanding issues is here:
https://github.com/yt-project/bb-migration/issues
The two things I think we need the *most* help with:
* Updating the documentation in the yt repository to change it to describe
how to fork, commit, etc, on GitHub rather than BitBucket.
* Update yt update to pull from GitHub rather than BitBucket.
If anyone can help out and try to knock some of these out, we should be on
schedule for a quick transition.
-Matt
New issue 1345: Add "north_vector" to field parameters
https://bitbucket.org/yt_analysis/yt/issues/1345/add-north_vector-to-field-…
Anonymous:
When I try to add/create fields for my dataset, I cannot call:
def _velocity_projected_north(field, data):
nv = data.get_field_parameter("north_vector")
.........
return v
ds.add_field(('gas','velocity_projected_north'), function = _velocity_projected_north,units="cm/s", force_override = True)
It would be great if north_vector is included in dataset
Responsible: MatthewTurk
