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

Improve Makefile to clean __pycache__ directory recursively #611

Merged
merged 1 commit into from
Sep 17, 2020

Conversation

seisman
Copy link
Member

@seisman seisman commented Sep 17, 2020

Description of proposed changes

Running make clean only deletes the pycache directory in the
project root. There are still a few pycache directory left in the
subdirectories.

Reminders

  • Run make format and make check to make sure the code follows the style guide.
  • Add tests for new features or tests that would have caught the bug that you're fixing.
  • Add new public functions/methods/classes to doc/api/index.rst.
  • Write detailed docstrings for all functions/methods.
  • If adding new functionality, add an example to docstrings or tutorials.

@seisman seisman added the maintenance Boring but important stuff for the core devs label Sep 17, 2020
@seisman seisman added this to the 0.2.x milestone Sep 17, 2020
@seisman seisman requested a review from weiji14 September 17, 2020 19:38
@seisman
Copy link
Member Author

seisman commented Sep 17, 2020

@weiji14 Just a quick off-topic question: should we use milestone 0.2.1 instead of 0.2.x? I think 0.2.1 is easier for us and others to track the changes in a single release. If we decide to release 0.3.0 instead of 0.2.1, it's also much easier to changes all 0.2.1-related PRs/issues to 0.3.0.

Copy link
Member

@weiji14 weiji14 left a comment

Choose a reason for hiding this comment

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

Looks good, didn't realize there were so many nested pycache directories!

One thing that bugs me is that the Makefile commands are very UNIX specific (i.e. it works on Linux/macOS, but not on Windows). But that's for a separate PR.

@weiji14 Just a quick off-topic question: should we use milestone 0.2.1 instead of 0.2.x? I think 0.2.1 is easier for us and others to track the changes in a single release. If we decide to release 0.3.0 instead of 0.2.1, it's also much easier to changes all 0.2.1-related PRs/issues to 0.3.0.

No strong preference, happy to go with it (though I do like that milestone v0.2.x is at https://github.com/GenericMappingTools/pygmt/milestone/2 and milestone v0.3.x is at https://github.com/GenericMappingTools/pygmt/milestone/3, but that is bound to break at some point).

@seisman
Copy link
Member Author

seisman commented Sep 17, 2020

One thing that bugs me is that the Makefile commands are very UNIX specific (i.e. it works on Linux/macOS, but not on Windows). But that's for a separate PR.

I believe we will fix it when a Windows developer joins the team.

No strong preference, happy to go with it (though I do like that milestone v0.2.x is at https://github.com/GenericMappingTools/pygmt/milestone/2 and milestone v0.3.x is at https://github.com/GenericMappingTools/pygmt/milestone/3, but that is bound to break at some point).

OK. I'll change the milestones later.

@seisman seisman modified the milestones: 0.2.0, 0.2.1 Sep 17, 2020
@seisman seisman merged commit f0bd178 into master Sep 17, 2020
@seisman seisman deleted the clean-pycache branch September 17, 2020 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Boring but important stuff for the core devs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants