Skip to content
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

allow vsearch merge-pairs to output unmerged reads #95

Merged
merged 1 commit into from
Dec 12, 2023

Conversation

colinvwood
Copy link
Contributor

No description provided.

@gregcaporaso
Copy link
Member

I'm realizing now that this is going to change the interface of merge-pairs.

I see two ways to go here:

  1. Merge this just after the 2023.11 release, and include in the 2023.11 release notes that this interface will be changing in the first release of 2024.
  2. We could add a parameter to q2_vsearch._merge_pairs.merge_pairs that toggles whether we create the unmerged reads output, and then have two actions that call that function - one that doesn't output the unmerged reads (i.e., the existing action) and a second action that does output the unmerged reads.

I'm leaning toward Option 1, to avoid action-bloat. Thoughts on this @colinvwood, @ebolyen?

@colinvwood
Copy link
Contributor Author

do we always warn of these sorts of changes one release cycle beforehand?

@gregcaporaso
Copy link
Member

Generally, yes - we like to announce interface changes one cycle before making them (and this changes the interface by adding a new required output - so analysis workflows that call this action will fail until the new output is integrated in the workflow). That gives folks time to update any automated workflows.

@colinvwood
Copy link
Contributor Author

I agree that the first option seems like the better way to go

@colinvwood
Copy link
Contributor Author

colinvwood commented Nov 28, 2023

I wonder though, since vsearch has never been part of the shotgun distribution, wouldn't adding it with these changes to that distribution not constitute a change of interface (but an introduction of one which is happening either way)? and the amplicon distribution can wait a cycle?

but that might not be possible because we would need two branches on vsearch one for each distribution release

I guess we could release amplicon then merge this then release shotgun

@gregcaporaso
Copy link
Member

Good point that it would be an interface change for the amplicon distro but not the shotgun distro. I'd be good with that plan, but I just wonder if it creates a lot of headaches for the release. Let's discuss in the engineering meeting today.

@gregcaporaso gregcaporaso self-assigned this Nov 30, 2023
@colinvwood
Copy link
Contributor Author

We're planning on merging just after the 2023.12 release for both distributions.

Copy link
Member

@gregcaporaso gregcaporaso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great overall. Just a couple of questions regarding test data, and one request for a test.

q2_vsearch/tests/test_merge_pairs.py Show resolved Hide resolved
q2_vsearch/plugin_setup.py Show resolved Hide resolved
q2_vsearch/tests/test_merge_pairs.py Show resolved Hide resolved
@gregcaporaso
Copy link
Member

Thanks @colinvwood!

@gregcaporaso gregcaporaso merged commit c8b3ace into qiime2:dev Dec 12, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Completed
Development

Successfully merging this pull request may close these issues.

2 participants