Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release version v0.4 #253

Closed
5 tasks done
caspervdw opened this issue Feb 17, 2017 · 13 comments
Closed
5 tasks done

Release version v0.4 #253

caspervdw opened this issue Feb 17, 2017 · 13 comments

Comments

@caspervdw
Copy link
Member

caspervdw commented Feb 17, 2017

It's been almost a year since the last release, and there have been some additions to PIMS. What do we want to get into v0.4? @tacaswell @danielballan @nkeim

API breaks
- [ ] clean the as_gray, dtype and process_func kwargs (#250)
- [ ] start implementing default pipelines (#247)

New readers

Performance

Docs

@danielballan
Copy link
Member

I have some (yet unpushed) branched where I've been exploring how PIMS might interface with dask. I think that could affect our thinking on the future of the pipeline decorator and the defaults we want to ship. My preference is to wait on API breaks until we have a clearer plan there.

On the other hand, I haven't been giving PIMS very much of my bandwidth recently, so if you want to forge ahead for now and worry about dask integration later, I'll happily defer.

@caspervdw
Copy link
Member Author

Hey @danielballan, dask integration is a fantastic idea! I did look into dask a while ago and I recall that it might replace the slicerator/pipeline infrastructure that we developed.

So it makes sense waiting for that before we go crazy on the pipelines.

I guess that dropping the kwargs is something that we will do anyway. We should supply a good alternative, which in this case might be 2 appropriate pipeline functions (as_grey, as_dtype). and an explanation how to implement process_func using a pipeline.

What would a dask-equivalent look like? We could already work the API in that direction.

I will probably be spending less and less time on pims/trackpy the coming months. Do you think you have the bandwidth to implement this dask-rebase?

@danielballan
Copy link
Member

Yeah, I can easily justify that as a day-job activity. I'll post my work so far as is later this week.

@caspervdw
Copy link
Member Author

Ok I am very curious on this! Tagging my coworker @rbnvrw because he may be interested in this dask-based lazy processing.

@danielballan
Copy link
Member

@caspervdw Would you like to tag 0.4 as is for pimsviewer's sake? I think dask compatibility will require more than just #254 and I don't want to hold you up.

@caspervdw
Copy link
Member Author

Yes especially #227 and the new readers would be great to have in a release. Then we leave the kwarg cleaning, pipelines and/or dask implementation for 0.5?

@danielballan
Copy link
Member

That sounds right. Which new readers? (Sorry if that's a dumb question, I'm a bit bleary at the moment.) Are there any PRs left to be merged in 0.4?

@caspervdw
Copy link
Member Author

The ImageReader, ImageIO, Moviepy, PyAV, wrappers, and the sequence of FramesSequenceND reader (ReaderSequence).

I guess we only need some docs and release notes before the release. Also, maybe a revision of the pyav export function.

@danielballan
Copy link
Member

Oh, you mean the readers that have already been merged since the last tag, not any additional ones. OK, I'm caught up. 🐑

OK, it sounds like between us we can crank this out this week then?

@caspervdw
Copy link
Member Author

Yup, just pushed #257 to finish the exporters. Only todo is now the docs.

@caspervdw
Copy link
Member Author

I also finished the docs. #261

@danielballan
Copy link
Member

I think v0.4 is good to go. @tacaswell, speak up if you disagree.

@caspervdw
Copy link
Member Author

Ok! I am starting the release now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants