You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's 19 open issues and 7 open pull requests, travis-ci is broken, it looks abandoned.
There were some efforts to integrate pyregion with Astropy and improve it, especially #54 by @sargas . But those failed because there wasn't a pyregion maintainer that did code review and merge PRs and make releases.
One option would be to add a note to the pyregion README and top-level docs page along the lines of "pyregion is no longer under active development. Please start using and contribute to the regions package".
I think it would be preferable, because regions is very young and not feature complete ore API compatible with pyregion and at the very least to compare regions and for tests it'll be good to have a working pyregion.
I am using pyregion on a daily basis, and while it has a lot of quirks (an API inconsistent with the rest of astropy, for example), it is powerful and necessary. So, I would favor (2). @astrofrog, might it be possible for all of the maintainers of astropy/regions to get commit priveleges on pyregion?
We might even consider making some of the astropy/regions features compatible with pyregion, e.g. a one way astropy/region->pyregion object converter.
If no-one else volunteers, and I'm given the commit bit for pyregion and access on PyPI, I could implement a minimal version of option 2 early next week, i.e. get install and tests passing again and make a release. Something minimal.
I'm not familiar much with the pyregion code base and don't have time to review something like #54 or judge if it's backwards-compatible enough or correct.
I think both approach are fine. There are existing conda packages for the latest release, so one can use those still for some time.
However if it's (2), I can help out with making the tests/infrastructure work again.
@keflavich@cdeil@bsipocz - all regions developers now have admin-level access to pyregion. In the long term we need to deprecate pyregion (once regions can do the same). It might be helpful to make a list of features that need to be implemented in regions before this can happen.
I'm closing this discussion issue now.
Thanks to everyone here for your input!
In the past days we've agreed on and largely implemented a solution.
For pyregion the continuous integration setup has been fixed, there's a link to the new regions package in place, and the pyregion v1.2 release is coming tomorrow.
Activity
keflavich commentedon Jul 29, 2016
I am using pyregion on a daily basis, and while it has a lot of quirks (an API inconsistent with the rest of astropy, for example), it is powerful and necessary. So, I would favor (2). @astrofrog, might it be possible for all of the maintainers of astropy/regions to get commit priveleges on pyregion?
We might even consider making some of the astropy/regions features compatible with pyregion, e.g. a one way astropy/region->pyregion object converter.
cdeil commentedon Jul 29, 2016
If no-one else volunteers, and I'm given the commit bit for
pyregionand access onPyPI, I could implement a minimal version of option 2 early next week, i.e. get install and tests passing again and make a release. Something minimal.I'm not familiar much with the
pyregioncode base and don't have time to review something like #54 or judge if it's backwards-compatible enough or correct.keflavich commentedon Jul 29, 2016
Oof.... #54 is a lot of work. I might be qualified to review it, but I don't have the time for the foreseeable future (though maybe on a flight...)
bsipocz commentedon Jul 29, 2016
I think both approach are fine. There are existing conda packages for the latest release, so one can use those still for some time.
However if it's (2), I can help out with making the tests/infrastructure work again.
astrofrog commentedon Jul 30, 2016
@keflavich @cdeil @bsipocz - all regions developers now have admin-level access to pyregion. In the long term we need to deprecate pyregion (once regions can do the same). It might be helpful to make a list of features that need to be implemented in regions before this can happen.
cdeil commentedon Aug 1, 2016
@bsipocz - Thanks for fixing continuous integration for
pyregionyesterday!cdeil commentedon Aug 1, 2016
@astrofrog - Thanks for giving us access to this repo.
So let's clean some things up and make a new release soon.
The last one is from October 2014 and as #55 remarks, points to outdated reco / docs pages:
https://pypi.python.org/pypi/pyregion/1.1.4
@leejjoon - At the moment I think only you have access on PyPI for
pyregion, right?Do you have time / interest to do the release?
If no, would you be willing to give the people from the new
regionspackage access, so that one of us can make the release?See https://pypi.python.org/pypi/regions
leejjoon commentedon Aug 1, 2016
I am willing to give others access to the package. Let me know a list of ids.
cdeil commentedon Aug 1, 2016
@leejjoon - Thank you!
My suggestion would have been to use the same list as
https://pypi.python.org/pypi/regions
Or, if you prefer, just add me for now, and I'll make a 1.2 release in the coming days and then add others later as needed.
leejjoon commentedon Aug 1, 2016
This should be done now.
cdeil commentedon Aug 3, 2016
I'm closing this discussion issue now.
Thanks to everyone here for your input!
In the past days we've agreed on and largely implemented a solution.
For
pyregionthe continuous integration setup has been fixed, there's a link to the newregionspackage in place, and the pyregion v1.2 release is coming tomorrow.