Namespace packaging

[oesteban]

shouldn't this:

https://github.com/nipreps/synthstrip/blob/dcc89bee00275374daeeaf6007ba90a35a4bdbca/pyproject.toml#L6

be

 name = "nipreps-synthstrip"

as per https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages?

And then also (https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#finding-namespace-packages):

[tool.setuptools.packages.find]
where = ["nipreps"]

[mgxd]

Yep, the name should absolutely be nipreps-synthstrip, that was a remnant of my earlier fiddling.

Not sure about adding a setuptools command though, hatchling should handle this automatically I believe (cc our resident hatchling expert @effigies)

[oesteban]

What about the other two submodules I proposed?

nipreps.interfaces nipreps.workflows

[mgxd]

I don't remember that proposal - are you suggesting the import should look like:

from nipreps.interfaces.synthstrip import SynthStrip

[effigies]

Not sure about adding a setuptools command though, hatchling should handle this automatically I believe

Yes, hatchling and setuptools will (per spec) ignore each other's config. I think you're right that this should work (I would just build and unpack the sdist and wheel to verify) as-is, but if you want to be explicit, you will want the package to be nipreps and you might use only-include = ["nipreps/synthstrip"]. See https://hatch.pypa.io/latest/config/build/#explicit-selection.

[oesteban]

I don't remember that proposal

Sorry, it's this - https://github.com/nipreps/nireports/pull/71#issue-1672572206

• are you suggesting the import should look like:

from nipreps.interfaces.synthstrip import SynthStrip

I think so, for the interface. But to ease our lives we can put the nipype interface with the other interfaces, and leave this package even more lightweight.

[effigies]

I would be up for trying to keep the interface and wrapped utility in the same package. We could even add a pydra task while we're at it.

nipreps/
  synthstrip/
  tasks/
    synthstrip/
  interfaces/
    synthstrip/

That way adapting the interface/task can be done in lockstep with changes to the utility and we can use PyPI don't need to depend on any versioning machinery in nipype or pydra.

I would keep nipype and pydra as optional dependencies.

[oesteban]

This would be a good topic to discuss in the next IT - don't you think?

cc/ @esavary

[mgxd]

My inclination is on keeping the namespace as lightweight as possible, and IMO nipreps.<tools> does enough to distinguish 1) what tool it is and 2) it is maintained by this organization.

I would keep nipype and pydra as optional dependencies.

+1 on anytime we can make the installation smaller.

What we could then do is create a separate cookiecutter (nipreps-submodules?) that creates the expected layout (building off chris's)

nipreps/
  synthstrip/
    <code>
    ...
    ext/
        nipype.py
        pydra.py

[effigies]

Yeah, I'm fine with bundling it inside one namespace. I would just be explicit and call the submodule wrapper or wrappers:

from nipreps.<tool>.wrapper.nipype import <Interface>
from nipreps.<tool>.wrapper.pydra import <Task>

[oesteban]

@mgxd can we finalize this? Having a pypi package would allow me to drop the code from mriqc and start using it elsewhere.

[mgxd]

@oesteban done

https://pypi.org/project/nipreps-synthstrip/

[oesteban]

Thanks!