Description
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.