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

Turn it into a proper Python package #611

Merged
merged 19 commits into from
Oct 3, 2022

Conversation

hoechenberger
Copy link
Member

@hoechenberger hoechenberger commented Sep 23, 2022

Fixes #580

Very much WIP at this stage, just trying to get the ball rolling.

cc @larsoner

Before merging …

  • Changelog has been updated (docs/source/changes.md)

@hoechenberger
Copy link
Member Author

@larsoner Now it actually installs and creates an entry-point:

❯ mne-bids-pipeline
ERROR: Missing required flags: {'config'}
Usage: mne-bids-pipeline <flags>
  optional flags:        --config
  required flags:        --steps | --root_dir | --subject | --session |
                         --task | --run | --interactive | --n_jobs | --debug |
                         --cache
  additional flags are accepted

For detailed information on this command, run:
  mne-bids-pipeline -- --help

@larsoner
Copy link
Member

Nice! Since all the mne commands are underscored like mne browse_raw here it probably makes sense for consistency to use mne_bids_pipeline ...

@hoechenberger
Copy link
Member Author

hoechenberger commented Sep 23, 2022

Nice! Since all the mne commands are underscored like mne browse_raw here it probably makes sense for consistency to use mne_bids_pipeline ...

mne_bids uses underscores too, so I suppose you're right. Although I have to admit I do not like the inconsistency between package name and entry point name! It's confusing … and the underscores are not very UNIX-y 🤔

@hoechenberger

This comment was marked as resolved.

@hoechenberger
Copy link
Member Author

hoechenberger commented Sep 24, 2022

@larsoner Using MNE's run_subprocess introduces an additional newline / empty line after each line printed by the logger here. Do you know how to fix this?

@larsoner
Copy link
Member

Why do you need run_subprocess?

@hoechenberger
Copy link
Member Author

Why do you need run_subprocess?

I only use it in run_tests.py to ensure all tests are run through the CLI!

.gitignore Outdated Show resolved Hide resolved
@hoechenberger
Copy link
Member Author

Re logging, I've opened a bug upstream: mne-tools/mne-python#11218

@hoechenberger hoechenberger marked this pull request as ready for review October 3, 2022 17:54
@hoechenberger hoechenberger reopened this Oct 3, 2022
@hoechenberger
Copy link
Member Author

hoechenberger commented Oct 3, 2022

@larsoner @agramfort
This should be good to merge once CI comes back green

The changes here allow installation of the pipeline via pip install . (editable mode supported as well), and python run.py ... can simply be replaced with mne_bids_pipeline ... but also remains available!

In followup PRs, we can add features like "please create a template config file" etc.

Once we have done that, I believe it's time for a first release!

Copy link
Member

@agramfort agramfort left a comment

Choose a reason for hiding this comment

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

@hoechenberger thanks

can you see if the doc needs any update?

@@ -316,5 +316,9 @@ def process(
logger.info('Done running 👆', extra=extra)


if __name__ == '__main__':
def main():
fire.Fire(process)
Copy link
Member

Choose a reason for hiding this comment

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

run.py is still useful?

Copy link
Member Author

@hoechenberger hoechenberger Oct 3, 2022

Choose a reason for hiding this comment

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

Yep, it was one of my goals here to get everything working with as few changes as possible!

But see #611 (comment)

Copy link
Member

@larsoner larsoner left a comment

Choose a reason for hiding this comment

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

A remarkably small diff actually!

I would prefer that we change the folder structure to reflect the standard scientific Python folder layout, i.e., nest all Python under a mne_bids_pipeline/* rather than at the repo root. The root would then just have docs, mne_bids_pipeline, and pyproject.toml.

@@ -30,7 +30,7 @@ jobs:
- name: Lint config.py with flake8
run: make flake-config
- name: Install codespell
run: pip install codespell
run: pip install "codespell @ https://github.com/Freed-Wu/codespell/archive/refs/heads/iss2055.zip" tomli # fork that supports pyproject.toml
Copy link
Member

Choose a reason for hiding this comment

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

-1 on this, let's push for codespell-project/codespell#2055 instead

Copy link
Member

Choose a reason for hiding this comment

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

... I see why you did this, so you could get rid of setup.cfg entirely. Let's keep it then and I'll fix this once the upstream PR is merged

BUILDING.md Outdated
* Create `sdist` distribution:

```shell
python -m build --sdist
Copy link
Member

Choose a reason for hiding this comment

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

you should always also create a wheel so that --only-binary ":all:" works

Copy link
Member Author

Choose a reason for hiding this comment

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

I usually never build wheels, thanks for the pointer

@hoechenberger
Copy link
Member Author

I would prefer that we change the folder structure to reflect the standard scientific Python folder layout

I actually actively wanted to avoid this until now, to cause as little disruption as possible to long-term users who expect to use run.py! But we can make the change if you think it'd make sense

@hoechenberger
Copy link
Member Author

hoechenberger commented Oct 3, 2022

@larsoner I will probably be busy for the next few days, please feel free to take over and coordinate with @agramfort if you want

Otherwise you'll just to have to wait for me :)

@larsoner
Copy link
Member

larsoner commented Oct 3, 2022

I think a lot of the internal mechanics might be simplified if we can make everything private by moving run.py to mne_bids_pipeline/_run.py etc. I've seen quite a bit of redundant code and gymnastics in all the automation routines that could be simplified by this. Just a few examples:

  1. No need for sys.path insertion because we can use proper package-relative imports like from ._scripts import ... rather than absolute from scripts import ... which failed before (for me at least)
  2. Code dedup between config.py and run.py, e.g., related to logging and imports
  3. Moving all helper functions out of config.py to a new _utils.py to make the config.py "pure" in the sense that it can contain just all the default config values -- so we can both use it ourselves, and copy-paste it to give people a default config (probably while commenting out all lines like in standard Unix config files)
  4. Simplification of doc building gymnastics due to interactions between variables (e.g., MAINT: Autogenerate step table #619 would be easier I think)

If we support python run.py ... for people rather than making them transition to mne_bids_pipeline ... we have to wait on this stuff :(

@larsoner
Copy link
Member

larsoner commented Oct 3, 2022

Okay I'll leave the refactor to a follow-up PR since it's going to be a lot of git mv that would be nice to keep separate from this package-related stuff. I'll just push a quick fix for my comments above and then mark for merge!

@hoechenberger
Copy link
Member Author

I think a lot of the internal mechanics might be simplified if we can make everything private by moving run.py to mne_bids_pipeline/_run.py etc.

Yep! That code will become much easier to maintain

@hoechenberger
Copy link
Member Author

Okay I'll leave the refactor to a follow-up PR since it's going to be a lot of git mv that would be nice to keep separate from this package-related stuff. I'll just push a quick fix for my comments above and then mark for merge!

Sounds good to me!

@larsoner larsoner merged commit e241d48 into mne-tools:main Oct 3, 2022
@larsoner
Copy link
Member

larsoner commented Oct 3, 2022

Thanks @hoechenberger !

larsoner added a commit to larsoner/mne-bids-pipeline that referenced this pull request Oct 3, 2022
* upstream/main:
  Turn it into a proper Python package (mne-tools#611)
@hoechenberger hoechenberger deleted the hoechenberger/issue580 branch October 4, 2022 05:45
@agramfort
Copy link
Member

agramfort commented Oct 11, 2022 via email

@hoechenberger
Copy link
Member Author

@agramfort I don't know the context of your response :) do you mean how we would need to update the docs? We already did do that!

@agramfort
Copy link
Member

Sorry this email was sent with a delay from my iPad …

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

Successfully merging this pull request may close these issues.

Making MNE-BIDS-Pipeline a proper Python package
3 participants