Core module and VRSATILE

[ahwagner]

My team (specifically, @jsstevenson) is currently working on extending the computed identifier routines from vrs-python to also support in-draft categorical variation concepts. @reece foresaw the need for this and split out computed identifiers into the ga4gh.core module. We need to discuss the best way to leverage this core shared across products; do we extend vrs-python to cover other VRSATILE concepts and just add modules accordingly? Or do we break out the core module from vrs-python and make it a dependency for both vrs-python and related vrsatile tools? Or some other solution?

@reece @larrybabb and @andreasprlic would like your thoughts.

[larrybabb]

My $.02... I like that the ga4gh.core is a separate package/module. It's pretty clear from the VRS-Python READ.ME that @reece foresaw the need to break the ga4gh.core package out into it's own repo. I don't see any reason to wait on this.

Here's the excerpt from the read.me

This repository contains several related components:

• ga4gh.core package Python language support for certain nascent standards in GA4GH. Eventually, this package should be moved to a distinct repo.

[reece]

Yep, the intent was to eventually break it out.

I didn't because 1) The name ga4gh.core is outside VR scope, so it felt to me that officially using this name merited discussion; 2) Splitting ga4gh.core and ga4gh.vrs into distinct packages makes concurrent development a little trickier.

[larrybabb]

Just a thought. We may want to have a package naming approach that is specific to GKS. I say this because ga4gh is much larger and broader than GKS. We are developing packages and core approaches that really haven't demonstrated the need to go beyond GKS thus far. Until such a time it may be prudent to use a ga4gh.gks.xxx package namespace. I know I would be a bit put off if one of the other workstreams presumed authorship of the ga4gh.xxx namespace.

I do appreciate that ga4gh.core is intended to span all of ga4gh, but I think we should take a stepwise approach to arriving there. As other's come on board with common cross-workstream ideas, then we should begin pushing for these broader namespaces.

Again, just looking ahead and trying to see through the eyes of non-GKS perspectives.

Maybe we can set a policy that at least one other workstream needs to be in favor of the use of the ga4gh.core namespace?

[reece]

I both like and dislike that idea, @larrybabb .

As I mentioned, I share the concern about usurping the ga4gh namespace.

However, putting organizational structure into package names conflates two very different goals. For example, what if ga4gh reorganizes or gks is renamed?

Perhaps TASC should provide guidance.

[larrybabb]

agreed. i think ga4gh could be renamed too. I think the concern of renaming the organization is a minor concern and distracts from the main concern. One could argue that regardless of the sub-org name we are still doing the work of genomic knowledge standards (gks) within ga4gh, which is therefore more meaningful and useful for the long term. But I do concede that TASC should have the final word as this situation is one of the key purposes that we pushed for its creation.

[ahwagner]

General consensus from today's leads call is that the core module can reside in the ga4gh.gks.core namespace on PyPI as this best reflects the nature of how computed ID prefixes are used today (only among GKS specs). We also decided that reference implementations for GA4GH Standards are appropriate to put at the top level under ga4gh, making ga4gh.vrs appropriate and preferred for the rest of vrs-python.

[github-actions[bot]]

This issue was marked stale due to inactivity.

[github-actions[bot]]

This issue was marked stale due to inactivity.