Release cobrapy 1.0

[Midnighter]

Making a cobrapy 1.0 release is a chance to introduce some breaking API changes, look at the current package design, and organize what belongs in cobrapy and what doesn't. This is about:

• core classes
• instance manipulation methods
• simulation methods
• convenience functions
• model i/o

[pstjohn]

Guidelines on what should or should not be in cobrapy would definitely be helpful if we can all agree on them. I'd probably lean on the permissive side, allowing things to get added as long as they met certain criteria.

I.e.,

• added no/minimal code to the core/ module
• had a peer-reviewed reference
• included unittests
• worked for a wide range of different models (maybe everything in the test models suite?)
• had appropriate documentation

Some rational re-organization of the different methods could also be useful. How current do we feel this graphic is?

source

Not that we should follow that specifically, but having a similar graphic and using imports like

from cobra.biased.strain_design import optknock

would be a nice way of organizing code. scikit-learn is a good example of a wide-reaching package that still manages to have some good organization into submodules.

[Midnighter]

I like your thoughts a lot. I'm up-to-date with all of those methods/areas but something similar as to the graphic would make me happy. It could be implemented either via package/module structure or via decorators for annotation. And sorry about the "epic" issues. We've started using zenhub.com and the issues connected to the epics are not visible here.

[cdiener]

I can see where you are coming from and it would definitely help to define that scope.

I am pretty indecisive concerning the submodules vs. packages issue. Having less stuff in core and more stuff in external projects definitely helps maintaining the package and avoids having code that does not get touched in years and gradually breaks over time (how would we ensure somebody will continue to maintain the code they contribute?). On the other hand it will make installation a bit more complicated, external packages might receive less review and our users might not be happy to suddenly see stuff gone from the package... For me as a developer neither of the two options poses a particular problem so I think it would be helpful to get feedback from the user base here.

I would say that we could ask that all future C extensions should be external packages. This has really helped with optlang and makes CI and installation much easier.

@pstjohn the image is really nice. The only outdated parts I see are "Constraints from omics data", "gap-filling" and the lack of ME-models.

[pstjohn]

On C extensions, I definitely agree.

On the submodules, I think as long as the features are unittested we'll at least know if / when we break them with core API changes. And then we can deprecate them if they don't get supported? (i.e., ArrayBasedModel)

[cdiener]

True. Maybe we would have to be a bit stricter with tests and use test skipping a bit less than we are doing now... :thinking: I was more worried about adding new submodules only to delete them a few months later because they did not receive updates/bug fixes. However, that has not really happened and is probably purely hypothetical.

[Midnighter]

Here are last night's meeting notes. (I will update the wiki.) And here is the poll regarding cobrapy scope.

[cdiener]

Lot's of this in now out-of-date or implemented. Closing in favor of a new discussion.