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

Feature request: package this project for multi-user system #34

Open
delocalizer opened this issue May 2, 2023 · 3 comments
Open

Feature request: package this project for multi-user system #34

delocalizer opened this issue May 2, 2023 · 3 comments

Comments

@delocalizer
Copy link

We'd like to be able to install this software on our HPC infrastructure and make it available to all users but as it stands that's not possible, the two hurdles being:

  1. The executable assumes that the two directories input/ and mappability/ are co-located with it, and writeable by the end user(s). This isn't compatible with a multi-user system where typically the executable will be in a read-only bin/ directory and input data location will vary by user.
  2. There's no install target in the top-level makefile so there's no simple method to customize the location of the executable and its libraries, in particular the linked bamtools library

Thank you; our users would be appreciative!

@aboyle
Copy link
Contributor

aboyle commented May 3, 2023

Since this software is only intended to be run once per organism, we haven't felt the need to install it on HPC infrastructure. Instead, you most users simply download the required BED files from our repository and use them in their own workflows or software pipelines. It may be that those wanting to use the blacklist are just looking for those BED files.

@mrendleman
Copy link

@delocalizer I have a similar use case, where I run it on HPC infrastructure for species without public blacklists. I've had decent luck using conda for managing Umap and ENCODE Blacklist installations.

I'd also advocate for HPC support, as I run it more than once per organism as more data becomes available.

@delocalizer
Copy link
Author

@mrendleman that's pretty much what our users have too - genomes and input datasets that may not be shareable, plus input datasets that may evolve over time. Having them each install their own conda env is a reasonable workaround for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants