names

[bendichter]

My preference for names would be:

• the namespace name is e.g. "speech" (speech.namespace.yaml)
• the repo name is e.g. "ndx-speech" (git clone ...ndx-speech.git)
• the package name is e.g. "ndx_speech" (from ndx_speech import Transcription)

We know all non-core namespaces are going to be neurodata extensions, so there isn't much point in having the ndx prefix there. It only serves a purpose for the repo and package names, where this will be alongside other repos and packages.

I know it's a little tricky having 3 different names, but that's the convention I've been using. Would it be possible to change the cookiecutter to use that convention?

One advantage to this is we can ask for the namespace name and then add on the ndx prefix ourselves, thus automatically adhering to that standard of using the ndx prefix.

[rly]

This is a hard decision.

The Python package name should be "ndx_*" because package names cannot have hyphens and should be unique.

Extensions will have a catalog repo in https://github.com/nwb-extensions/ . Since we generate this repo, we can make the name be whatever we want, e.g. "ndx-speech-card" (like a catalog card. conda uses the suffix "feedstock" which I dislike). Repos generally use hyphens rather than underscores, so I would go with hyphens here. Adding "card" prevents the catalog repo from being confused with the source repo.

I envision that users can install approved extensions (i.e., download the source code) in two ways:

1. Go the catalog website (to be made), search for the extension by name (which can treat underscores as hyphens), go to the catalog webpage for the extension, and click "Download files", which will download the source code for the given version from GitHub/BitBucket or PyPI.
2. Run pynwb install ndx-speech in the command line or installExtension("ndx-speech") in Matlab. Calling these scripts would convert underscores to hyphens and append "-card" in order to find the catalog entry repo, and then download the source code for the given version from GitHub/BitBucket or PyPI.

The user is shielded from whatever the extension developer has called their project repo on GitHub/BitBucket/etc. or their package on PyPI, so the developer can call those whatever they want. But the template should encourage a default name for the developer's project repo. Since GitHub repos and PyPI packages use hyphens more often than underscores, I would use e.g. "ndx-speech".

Regarding the namespace name in the files <name>.namespace.yaml and <name>.extensions.yaml and the value of the key namespaces.name in the namespace yaml file (the value is written to file under the /specifications group):

The only places that the user should use/see the namespace name in their code is via:

load_namespaces('<name>.namespace.yaml')

and

ns_builder.include_type('...', namespace='<name>')

if they are writing a new extension.

While I appreciate the cleanliness of dropping the "ndx-", I think it would be easier for the user not to have to remember to drop the "ndx-" here. That said, the user still needs to remember to use "ndx-" and not "ndx_". I think this is tolerable, and we can catch those errors in the API.

tl;dr

My preference for names would be:

• the namespace name is e.g. "ndx-speech" and the filename "ndx-speech.namespace.yaml"
• the default source repo and PyPI package name are e.g. "ndx-speech"
• the catalog repo name is e.g. "ndx-speech-card"
• the Python package name is e.g. "ndx_speech" (from ndx_speech import Transcription)

[rly]

The name of the <name>.namespace.yaml can further be hidden from the user if we go with option 1 in #9. Not sure how that would look in Matlab.

[bendichter]

Ok thanks for the explanation. You don't want to use pypi for for Python installations? Then you'd have to do dependency management yourself. You need to work out environments, uninstall, etc. why not just use pip?

[rly]

Hm. Yes, dependency management would be a pain.
Option 1 (website) could be changed to tell people how to download and install the extension using Option 2.
For Option 2, if the user is using pynwb install ndx-speech, then pip can be called under the hood. The important step is querying the catalog repo.

[bendichter]

So pip install ndx_speech and pynwb install ndx-speech would do the same thing?

…

On Fri, Jun 21, 2019, 7:57 PM Ryan Ly ***@***.***> wrote: Hm. Yes, dependency management would be a pain. Option 1 (website) could be changed to tell people how to download and install the extension using Option 2. If the user is using pynwb install ndx-speech, then pip can be called under the hood. The important step is querying the catalog repo. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AAGOEETMZYR3F46PR3F53GDP3VTGLA5CNFSM4HPXAQ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJ3BLI#issuecomment-504606893>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGOEEQZ66HDHZU3NEADDVDP3VTGLANCNFSM4HPXAQ6A> .

[rly]

No, pip install ndx_speech would download the latest version from pip. This version is not necessarily approved by us. pynwb install ndx-speech pulls data from the catalog, which requires explicit approval and testing.

[rly]

I mean, pynwb install ndx-speech would call pip install ndx_speech==version based on the data from the catalog entry.

[bendichter]

Got it. Yeah that sounds like a convenient solution

…

On Fri, Jun 21, 2019, 8:01 PM Ryan Ly ***@***.***> wrote: I mean, pynwb install ndx-speech would call pip install ndx_speech==version based on the data from the catalog entry. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AAGOEEX3V2APKROG4CCBE6TP3VTW7A5CNFSM4HPXAQ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJ3FUI#issuecomment-504607441>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGOEEQT2AN7EFUPLOKMGS3P3VTW7ANCNFSM4HPXAQ6A> .