consider restructuring this project as a python library instead of a pipeline

[aryarm]

depending on how our needs pan out, we might prefer a command line method, instead

[aryarm]

On second thought, it seems like only some of this code would be useful as a command line tool, but the rest (executing FINEMAP and SuSiE and whatnot) fits better in Snakemake (see gymrek-lab/happler#31)

new strategy: move everything above this line in the Snakefile into a subcommand within our other repository and then install and call our subcommand from the Snakefile

potential drawback: if we call the subcommand multiple times, we'll be duplicating the work of loading the VCF, turning it into a genotype matrix, etc - so maybe we just use our python API from the snakefile instead of calling the subcommand.
Or we think about a way to get the subcommand to support rerunning the phenotype generation step within it

[aryarm]

ok, we met with everyone on monday to hash this out
so here's a revised proposal for a new, new plan:

• this repository becomes the home for the simulation work
• the data module gets moved into this repository as a submodule so that it can be imported in other repositories
• we make this repository into a poetry project and have an API documentation using sphinx and readthedocs
  • poetry will allow us to easily define dependencies and make the project installable from a github url, at least until we decide to publish it on pypi or wherever
  • add click subcommands
• we install this package as a dependency of happler using the aforementioned git install mechanism (see use poetry v1.2+ gymrek-lab/happler#10)
• we build code within happler that imports this code to create a happler simulate subcommand capable of creating all of happler's simulation data
• @mlamkin7 and I will keep different branches off of main for each of our respective contributions to this repo
• we setup and follow a shared set of guidelines for contributing, perhaps like happler's or trtools's
• we keep this repository private until we're ready to publish. public so that we can easily interface with it through readthedocs and install it in other projects.
  • we put up a message on the README to warn users not to use this until we've made our first public release
• we can keep the current snakemake workflow directory but adapt and add to it with each of the specific use-cases where we use the simulation library
  • since it's in a different subdirectory, it should be excluded from the standard poetry package install
• we consider new names for this repo haha
  • I think we can do better than "simulate_gwas"
  • Update: we're gonna go with "simwas" for now

@mlamkin7, what do you think?