strict_bounds parameter for AssemblyMapper

[cassiemk]

We currently use AssemblyMapper to convert g_to_c to get the final var_c. We would like to use strict_bounds=false for some calls, but not a global_config because we map multiple variants simultaneously. We noticed AssemblyMapper doesn't have the option to set strict_bounds. The AlignmentMapper's g_to_c just gives the cds interval, but we need the var_c. We looked into modifying AssemblyMapper to set the strict_bounds parameter but it looks like there are a lot of code changes needed to accommodate strict_bounds. Is this the best way to proceed or do you have any suggestions?

[reece]

@cassiemk : Your understanding is unfortunately correct: you cannot currently set strict_bounds for a single projection.

I remember disliking this limitation when implementing it. I would welcome a per-invocation option.

As you note, this feature would require extensive changes. In addition to the obvious need to pass strict_bounds through the entire call path, it would also require making that parameter available in hard-to-reach corners of the code. The most awkward of these is that the BaseOffsetPosition class uses strict_bounds in its validate() method, which can be called just about anywhere. Passing strict_bounds there simply isn't feasible.

A possible solution is to use a Python context manager to provide isolated sets of globals for selected invocations.

[cassiemk]

We had a follow-up question to this strict_bounds issue. Since our application uses concurrency, we were worried about using context_managers because we don't know if it will work with our concurrent solution. Instead, we went with an approach where we created two copies of the hgvs package (and called the second one hgvs2) using a symlink in the python site-packages directory. This allowed us to set one of the hgvs package's strict_bounds flag to True and the other set to False. However, because of the format of the import statements within the hgvs package, in the hgvs2 package, it would end up calling code in the hgvs package. For example, it would see an import line like: "import hgvs.validator" and go to the hgvs package instead of the hgvs2 package. Therefore, it would only ever use the hgvs package code (with the strict_bounds flag set to True) by the time it got to the alignment mapper code regardless of which package we called using our code. Our thought was that we could perhaps correct this by changing imports like "import hgvs.validator" to "from . import validator." Do you see any issues with changing the imports in this way? Thanks!

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[reece]

This issue was closed by stalebot. It has been reopened to give more time for community review. See biocommons coding guidelines for stale issue and pull request policies. This resurrection is expected to be a one-time event.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.