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

Rename and refactor package #76

Closed
2 tasks done
sdhutchins opened this issue Sep 27, 2017 · 18 comments
Closed
2 tasks done

Rename and refactor package #76

sdhutchins opened this issue Sep 27, 2017 · 18 comments

Comments

@sdhutchins
Copy link
Member

sdhutchins commented Sep 27, 2017

Before the official release, we need to decide on renaming the package and refactoring it.

  • Rename repository from Datasnakes-Scripts to OrthoEvolution
  • Refactor Datasnakes to OrthoEvol

Feel free to change the name of this.

@sdhutchins sdhutchins added this to the Official project release milestone Sep 27, 2017
@datasnakes datasnakes locked and limited conversation to collaborators Sep 27, 2017
@grabear
Copy link
Member

grabear commented Sep 27, 2017

I like OrthoEvol! Lets discuss this tomorrow during our meeting.

@grabear
Copy link
Member

grabear commented Oct 2, 2017

I like OrthoEvol. It sounds good, and it's on point for this project. If we link to this package in a publication, then it will make more sense for people as well. But we could also give at more general name and a more general function, and add more to it as we develop our other projects. What do you think? @sdhutchins.

For the short term I really like OrthoEvol, especially for publication. But if we decide to keep developing this package, we may pigeon hole ourselves with the name, and it could become confusing for users. So for the long term, the question remains.. How will we continue developing this package, and how will our future projects use it?

@grabear
Copy link
Member

grabear commented Oct 2, 2017

  • OrthoEvol
  • BioPipe
  • SnakePipe (LOL)
  • GenePipe
  • GenieInAFlask
  • Genie

@sdhutchins
Copy link
Member Author

lol at Genie in a flask. That made my day. I needed to smile.

@sdhutchins
Copy link
Member Author

I like OrthoEvol. It sounds good, and it's on point for this project. If we link to this package in a publication, then it will make more sense for people as well. But we could also give at more general name and a more general function, and add more to it as we develop our other projects. What do you think? @sdhutchins.
For the short term I really like OrthoEvol, especially for publication. But if we decide to keep developing this package, we may pigeon hole ourselves with the name, and it could become confusing for users. So for the long term, the question remains.. How will we continue developing this package, and how will our future projects use it?

I'll say this much...I agree about it for making the process of publishing a paper about the software easy. I think it's key we decide what we ultimately want out of this. For the GPCR and KARG projects, this is perfect and it's also perfect for other subsequent genomics or phylogenomics projects.

I think it's always possible to create a new package for other projects and/or turn something like the tools, manager, or cookies module of this project also into pypi projects...It'd actually be easy to do that and could garner more attention as well as allow us to use those packages in subsequent projects. It just all depends on how you see it.

We could have a genomics-project-manager package that includes Manager and Cookies. I'm just spitballing here. I see it a number of ways...all of which I'm cool with.

I've been looking over ete's paper and repo for some guidance. I'm not the biggest fan of the actual code in the project, but I enjoy the functionalities and their website.

@grabear
Copy link
Member

grabear commented Oct 3, 2017

Ok. I mean you're right. We could make a sort of utilities/tools PyPi package that includes:

  • Cookies
  • Manager
  • Pipeline
  • Tools

And a separate package for everything else:

  • Orthologs
  • RNA-seq
  • Microbiome
  • Etc...

This would allow us to develop our BioInformatics stuff outside of our Tools/Utilities stuff that we (and others) could develop for a wide genre of projects.

If we make that split we have got to do ASAP. But first we need to get our package stable:

@grabear
Copy link
Member

grabear commented Oct 3, 2017

We could call the Utilities/Tools:

  • Plumber
  • PiedPiper
  • Drano
  • Yoshi
  • Wario
  • Mario
  • PipeLabyrinth

Idk lol. Ideas @sdhutchins

@sdhutchins
Copy link
Member Author

I can think we can keep this package as is and still make packages for the tools. Yes, I'm being lazy lol

@grabear
Copy link
Member

grabear commented Oct 3, 2017

Lol. Alright. So keep everything inside, and when we get ready, we can basically carbon copy our "Plumber" modules into a new package. We'll just have to make sure those tools only depend on each other. I think that's how they are functioning at the moment as far as I'm aware.

@sdhutchins
Copy link
Member Author

lol Yes, if that's okay. I mean, we can do that at any time if wanted.

We could call the Utilities/Tools:
Plumber
PiedPiper
Drano
Yoshi
Wario
Mario
PipeLabyrinth
Idk lol. Ideas @sdhutchins

LMAO

@sdhutchins
Copy link
Member Author

I love all those names though.

@sdhutchins
Copy link
Member Author

@grabear Thought about this a few days ago. I really do think we should keep it designed for orthology inference or phylogenetics.

I think trying to incorporate rnaseq (and likely R) would be more complex. Also, I think we've created tools within this tool that we can offer as standalone tools from the Manager module to sge to the Cookies template to ftp. It'd improve our skills to develop more packages, and we'd also improve our resumes. By all means, we could take on these packages as individuals which would also be something to tout on our resumes or in future interviews (showing we can develop software in a collaborative manner and independent manner).

Just my thoughts.

I also think for the science community...having more and simpler tools that do great things can be more valuable than 1 big-complex tool (which can scare people off).

Let me know what you think. It'd be also great to get input from others about it as well.

@grabear
Copy link
Member

grabear commented Nov 9, 2017

Yea I can see that. BioPython for instance was pretty confusing at first.. I still like this idea though...

We could make a sort of utilities/tools PyPi package that includes:

Cookies
Manager
Tools

And a separate package for everything else:

Orthologs
RNA-seq
Microbiome
Etc...

What if we do a "bio-utilities" package and then an "ortho-evol" package that takes bio-utilities as a dependency?

@grabear
Copy link
Member

grabear commented Nov 9, 2017

For above though ortho-evol would be separate from anything we did with RNA-seq data or micro-biome data.

@sdhutchins
Copy link
Member Author

Yeah, I think we can keep the current package as is and convert it to ortho-evol.

We can make those utilities you mentioned (Cookies, Manager, Tools) still separate or we can do it how you laid out. I really think each deserves their own pypi package or multiple ones - particularly the concepts.

I'm all for us having like 5 packages that we can use and put out there into the world. It was sort of where I was going with the py3utils and biosnips repos.

Manager could be designed as such that you could port in multiple projects into one project manager. You could call it bioproject or biomanager. Idk. We can get creative.

I mean the BioSQL stuff you've done should for sure be a pypi package. It can still be in this, but a package as well would be great.

One of the features of this package is project management and I think it's important it stays, but remains more specific to what we need to finish this project.

@grabear
Copy link
Member

grabear commented Nov 9, 2017

Ok. I'm going to think about this. I'll look at the dependencies for everything tomorrow.

@sdhutchins
Copy link
Member Author

Addressed by #128

@sdhutchins
Copy link
Member Author

#127

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

No branches or pull requests

2 participants