Comments (24)
I agree it's confusing. The question is who has a stronger claim.
from asdf.
See also #120 of which this is sort of a duplicate.
from asdf.
Hi all,
I agree that this is very unfortunate and confusing. For what it is worth we actually tried to rename everything a while ago once we realized the conflict. Some people higher up decided that it is too late to change the name and thus we are stuck with it. I strongly assume the same is true for you as well.
This is all the worse as your format seems to gain some traction and we are also finally done and have the hope and somewhat justified expectation that it will become the new standard for seismology.
I'm sorry - I kind of missed #120. As already noted you have pyasdf
on readthedocs and asdf
on pypi. We have the inverse. So we should definitely swap. Whoever ends up getting asdf
should also rename their pyasdf
package and install name to make it easier for everyone.
Unfortunately this will still be very confusing :-( What about renaming both packages to asdf_space
and asdf_seismo
or something along these lines? We should still retain a hold on the asdf
and pyasdf
pypi names to avoid future conflicts.
We should probably also both add short notes to the top of each of our repos/websites that point to the existence of the other format, e.g.
This is the
Advanced Scientific Data Format
- if you are looking for theAdaptable Seismic Data Format
please go to http://seismic-data.org
and
This is the
Adaptable Seismic Data Format
- if you are looking for theAdvanced Scientific Data Format
please go to http://asdf-standard.readthedocs.org
Looking forward to hear some other opinions/suggestions.
Cheers!
from asdf.
FWIW our ASDF is for more than astro, so asdf_space
wouldn't work. Another problem is that in both our cases the Python package itself is named pyasdf
so that won't do.
Since we already have "asdf" on PyPI, I'd be amenable to changing the name of our Python package to just asdf
to match that (@perrygreenfield? -- this would of course necessitate changing some imports in the JWST libs but a quick find/replace should do it). Then we should of course exchange the readthedocs accounts. I think trading readthedocs accounts will cause much less havoc than trading PyPI distribution names.
Also agreed about adding the disclaimers.
from asdf.
FWIW our ASDF is for more than astro, so
asdf_space
wouldn't work.
Yea...I just read up on it - it is actually really cool. It would even be conceivable to base our ASDF format on yours which which confuse things even more ;-) Maybe asdf_science
or something would work but I agree that that is a bit cumbersome.
Another problem is that in both our cases the Python package itself is named
pyasdf
so that won't do.
My proposal included to also rename the actual Python package import names so it is very clear to users what they are importing.
Since we already have "asdf" on PyPI, I'd be amenable to changing the name of our Python package to just asdf to match that (@perrygreenfield? -- this would of course necessitate changing some imports in the JWST libs but a quick find/replace should do it). Then we should of course exchange the readthedocs accounts. I think trading readthedocs accounts will cause much less havoc than trading PyPI distribution names.
I'm very ok with this. If there are some big issues for you let me know and I'll talk to my collaborators about renaming our package to asdf
.
Also agreed about adding the disclaimers.
Great. I'll add them right away. Which website/repository should they link to? For the disclaimers on your sites please link to http://seismic-data.org.
from asdf.
http://asdf-standard.readthedocs.org/ is fine for now.
from asdf.
Hi,
I just started to package (py)asdf for Debian, and @cdeil pointed me to this issue. We still don't have another asdf or pasdf package, and also no announced packaging of the seismic package, and we do a "first comes" solution of conflicts. However, it would be nice to have a definitive solution before I finally upload the package, so that the seismic people don't run into confusion when they want to use Debian.
from asdf.
This was recently pointed out as well, but I haven’t figured out a good solution. Do you have any suggestions? I really hate to change the name yet again.
Perry
On Feb 6, 2016, at 8:15 AM, Ole Streicher [email protected] wrote:
Hi,
I just started to package (py)asdf for Debian, and @cdeil pointed me to this issue. We still don't have another asdf or pasdf package, and also no announced packaging of the seismic package, and we do a "first comes" solution of conflicts. However, it would be nice to have a definitive solution before I finally upload the package, so that the seismic people don't run into confusion when they want to use Debian.
—
Reply to this email directly or view it on GitHub.
from asdf.
Unfortunately not. I just feel that it is a bit unfortunate since seismology is also science, and at the end not so far away from astronomy. And since "our" asdf is not really astronomy related (except for its history), the development may end up in that seismologists use two ASDF formats: one "seismology", and one "science" data format. And then, they use two python packages with the same name to access them. Imagine how complicated it would be to write a converter from one format to the other...
from asdf.
There is one possible change that has been discussed above by @embray and @krischer and I think agreed upon, but then it wasn't implemented.
Rename the astro package from pyasdf
to asdf
, to make it consistent with it's name on PyPI, and make it possible to have both packages installed in a given Python installation.
There can still be confusion about two data formats with the same name, and two packages with very similar names, but going all-in to asdf
for the astro package and pyasdf
for the geo package is an improvement over the current situation (both install as asdf
in site-packages), no?
from asdf.
asdf seems like a reasonable alternative. Let me discuss it Monday with some others.
from asdf.
There can still be confusion about two data formats with the same name, and two packages with very similar names, but going all-in to asdf for the astro package and pyasdf for the geo package is an improvement over the current situation (both install as asdf in site-packages), no?
The seismo package currently installs as pyasdf
, and yours as asdf
so nothing would need to be changed from that perspective - you would need to change your import name to asdf
. Then both packages could be used side by side.
A couple post ago I also brought up the idea of giving both packages more descriptive package names as well as import names, e.g. asdf_science
and asdf_seismo
. It is a bit ugly but we would trade that for a vastly reduced change of confusing people. Opinions on this?
Nonetheless having asdf
and pyasdf
as two separate things everywhere is an improvement on the current sitation. The APIs to both are quite different so people would notice really quickly if they got the wrong package. Our communities also don't really overlap so I guess the biggest overlap will be people that google ASDF and potentially a bit within the Python community.
Assuming we go forward with this and everyone agrees - just to be clear: We get pyasdf
and you get asdf
everywhere. For now this entails read-the-docs, pypi, import, and package names. For the debian (and other distros), could we agree on python(3)-asdf_science
& python(3)-asdf_seismo
?
from asdf.
The seismo package currently installs as pyasdf, and yours as asdf
@krischer - No, currently the astro package installs as pyasdf as well:
from pyasdf import AsdfFile
http://pyasdf.readthedocs.org/en/latest/#getting-started
But your conclusion about what to do at the end is correct, I think.
(I'm unsubscribing from this thread. I just noticed this issue as a user of the astro asdf package, i'll leave it to you devs to sort this out.)
from asdf.
@krischer - No, currently the astro package installs as pyasdf as well:
It installs as asdf
into site-packages
- well the .egg-info
at least I guess. So it is installed and uninstalled via asdf
. The import name is pyasdf
(which also results in a folder in site-packages
...).
from asdf.
@krischer I think that "asdf" for the science format reader and "pyasdf" for the seismology format reader is some compromise. However: The problem will re-appear for any other reader. How should a C library be called? libasdf is the only reasonable choice. Tcl (maybe, someone would write one for DS9...)? Javascript? etc. What about tools? asdf-science already has an "asdftool", is this a name that will never appear for seismologists? I know it is not popular, but can't one format or both be renamed? Like ascdf and asedf? -- this is however just food for thought; I myself care more for the (current) Debian package naming yet.
For the naming under Debian: as said above, if @perrygreenfield resp. @embray would change this, I would fine with the package called from Python as asdf
, like
from asdf import AsdfFile
What concerns the package names: we have a source package name and binary package names. The binary package name for a python module should be python-asdf
resp. python3-asdf
by our Python policy. The source package name could be something like python-asdf-science
(Debian does not allow underscores here), but the source package name is mostly invisible for end users. I would however keep a "python-" prefix there to mark is as a python package.
from asdf.
I'd just like to mention that I plan to upload the science/astronomy asdf package to Debian next week with following names.
- source package:
asdf
- Python-2 and Python-3 module name
asdf
(so,import asdf
) - binary Python-2 package:
python-asdf
- binary Python-3 package:
python3-asdf
- binary package with the tool:
asdftool
(if useful)
These names are then blocked for other Debian packages, f.e. for seismology. Please express a veto if a change or further discussion is needed.
BTW, is the asdftools useful to package or just an example?
from asdf.
That�s fine with us (and we need to deal with the readthedocs issue to (a swap is easiest I think))
Perry
On Feb 23, 2016, at 11:42 AM, Ole Streicher [email protected] wrote:
I'd just like to mention that I plan to upload the science/astronomy asdf package to Debian next week with following names.
� source package: asdf
� binary Python-2 package: python-asdf
� binary Python-3 package: python3-asdf
� binary package with the tool: asdftool (if useful)
These names are then blocked for other Debian packages, f.e. for seismology. Please express a veto if a change or further discussion is needed.
BTW, is the asdftools useful to package or just an example?�
Reply to this email directly or view it on GitHub.
from asdf.
sorry for the delay on our side everyone. Reading through this history looks like there may be some things to work out for the debian packages, but the readthedocs changes are agreed upon by all. @krischer, if that's still true, can we coordinate swapping names for RTD?
from asdf.
I'd of course still be happy to do the switch - I just had a couple of stressful weeks and forgot about it - sorry about that.
Can we do it at the beginning of next week? I'd rather not have everything offline over the weekend...
So just as a summary:
- You get
asdf.readthedocs
- we getpyasdf.readthedocs
. - You use
asdf
on pypi/conda/debian/... and we usepyasdf
- these are also the install names of our respective python packages.
Does that work for everyone?
We'll also add a note at a well visible spot on all our websites/docs/repos saying which ASDF format we are and put a link to yours as well. It would be great if you could do the same - this should help to minimize confusions.
from asdf.
No problem at all - beginning of next week would be perfect.
I think we're all in agreement of those points (anyone speak up now or forever hold your peace) and we'd be fine to put a disclaimer and redirect on your page to prevent confusion.
from asdf.
@krischer, when is a good time to move? I'm free tomorrow morning (EST) and can quickly perform the switch - not sure what time-zone you're in?
Wednesday is also good pretty much all day.
from asdf.
@justincely: What is your readthedocs handle? I guess we can just add each other as maintainers and then the new person delete's the other person as a maintainer and we perform the swap that way. There does not seem to be a way to hand over projects on rtd otherwise. My handle is also krischer
on rtd.
from asdf.
That's a good idea. I've added you to pyasd, my handle is the same: justincely
from asdf.
Great. I've also added you to asdf
. Feel free to remove me from it then you have full control. I'll do the same to the pyasdf
project in like a day or two in case you still need access for some reason.
from asdf.
Related Issues (20)
- Combine package and build workflows
- masked arrays do not roundtrip with all false masks
- `AsdfSpec` misses expected match
- deprecate `AsdfSpec` and `format_tag`
- Tracking `sunpy` 6.0 and ASDF 1.6.0 HOT 2
- Old (<2.14) versions of asdf do not fully support ASDF standard 1.6.0
- `AsdfFile` instances are not pickleable HOT 1
- Chunking support HOT 2
- Investigate enabling `validate_checksum` as default `True`
- Investigate returning `ndarray` when `lazy_load=False` HOT 8
- Change scope of ndarray custom validators HOT 1
- Add to docs comparison of `tag` vs `$ref` usage in schema.
- Consider a new design for the info and search methods that avoids conversion of nodes when the lazy_tree option is used
- Fix stable docs version in RTD
- FAILED asdf/_tests/test_yaml.py::test_implicit_conversion_warning HOT 3
- `assert_tree_match` and `np.testing` ignores array masks
- Schema_info Returning Non Schema Keyword HOT 2
- ignore_version_mismatch doesn't appear to be used? HOT 10
- Deprecate and remove the now unused `ignore_version_mismatch`
- `asdf.util.load_yaml` fails on recursive object
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asdf.