-
Notifications
You must be signed in to change notification settings - Fork 13
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
Reorganizing module hierarchy structure to remove ODM2 folder #146
Comments
@lsetiawan, a question about the sphinx documentation: what happens once we merge your PR #146 (assuming it does what we want), in terms of the API Sphinx documentation? Now there'll be two valid module paths, one with the For reference, here's the API doc for |
For the sphinx, I'd probably have to update the |
Ok. So we control that. Cool.
Exactly |
Done in #147. Closing. |
Thanks for closing. I guess regarding the docs:
The updates should be done only when issue a new release. |
I can update that now, so it will be included in the new release. |
Great, thanks. |
I'm reopening this issue as a reminder that in a future release (date TBD), we'll remove support for the now-deprecated "ODM2" package module hierarchy. That, import statements such as this one: odm2api.ODM2.services.readService will eventually no longer be supported, and only the new hiearchy will be supported: odm2api.services.readService |
Note to self: Make sure to read #159 for "definitive" findings about the preservation of git history after the module moves. |
We started discussing this some time ago at #135
@lsetiawan's PR #145 is intended to create a very nifty deprecation pathway to implement the reorganization and removal of the
ODM2
folder.Background discussions (copied from #135)
Emilio:
There's one issue that I think needs to be discussed soon, before odm2api can be seen as really stable. Currently the package has a packager/folder hierarchy that includes a now-useless "ODM2" folder:
https://github.com/ODM2/ODM2PythonAPI/tree/master/odm2api/ODM2
That forces most module import statements to include the useless ODM2 package hierarchy (eg,
odm2api.ODM2.services.readService
). We'll need to get rid of the ODM2 folder hierarchy, and the sooner we do it the better, to minimize disruptions. I strongly recommend that we do it in the next release, giving ourselves plenty of time for all code that uses odm2api to make the adjustment.Anthony:
I'm very much a fan of moving forward soon with the next release to remove the useless "ODM2" level of hierarchy (clipped unrelated comment). With release v0.7 minted as is, any software that depends on the old conventions still have handy access to that version, while we can move forward with migrating our actively developed stuff to our widespread conventions.
The text was updated successfully, but these errors were encountered: