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

Change name of utils folder #4

Open
david-castillo opened this issue Dec 18, 2017 · 7 comments
Open

Change name of utils folder #4

david-castillo opened this issue Dec 18, 2017 · 7 comments

Comments

@david-castillo
Copy link

Hi,

When installing the tool-api I got a conflict with another package that was already using utils. Would it be possible to change the name to something less common like mg_utils ? Or move utils inside a mg-tool-api folder?
Bear in mind that this may happen also with apps, tools, ...

For discussion

David

@marcopasi
Copy link
Member

Hi David,
Absolutely, this needs to be done asap, thanks for bringing it up. The choice of a strategy to do this would benefit from a decision about the global structure of the MuG libraries, which may now be timely.

What about putting all the submodules you mention within a MuG namespace? The distutils/setuptools wizards out there might confirm whether this can be done using some configuration magic (are namespace packages relevant in this context?).

More importantly I fear there is no way to do this without breaking dependants, so deployment should be arranged carefully...

@markmcdowall
Copy link
Member

So I have had a look at this as a similar issue cropped up when we were trying to create more repos based off of the original mg-process-test repo and found that the tool dir was clashing when importing other repo for the re-use of tools. For this we have moved the code down a level, including the tests into a folder like mg_process_fastq.

I have created a new branch called refactor_module where I have moved all of the Tool API code dirs (apps, basic_modules, tool, test and utils) into mg_tool_api.

The changes have been uploaded. If someone could have a look at the code and see if this fits that would be great. It will require coordination with others that have used this code as there are some major changes.

Cheers,

Mark

@david-castillo
Copy link
Author

Hi Mark,

I'm working now in updates of my workflows for the tadbit tools in our development VM. I'll test the changes in the tool-api at the same time and let you know if it works as expected.

Thanks

David

@markmcdowall
Copy link
Member

Hi David,

That would be great. The changes are on the branch refactor_module.

Mark

@markmcdowall
Copy link
Member

If these changes work for you, I'll start making further changes to the mg-process-fastq module as I have had to made the same changes there as we were getting clashes with the tool directories.

If the changes in mg-tool-api work for you, then I'll put in a pull request to merge them into the master branch.

Cheers,

Mark

@marcopasi
Copy link
Member

While we're on refactoring, I would like to deal with the demos also. I had thought of this some time ago (see the very old branch "demos_folder") but I wonder whether this is still relevant.

Are demos really useful? Will they ever be executed? Or can we safely remove them?

@markmcdowall
Copy link
Member

I'm happy removing them. If the examples in mg-process-test are ok with you as a way of using the API and setting up the repo then it should be fine to just remove them. If they cover a separate usage case then they could be copied over to that directory and added in like the testTool.py

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