Change delphin namespace to pydelphin?

[goodmami]

This issue is a request for user input.

The package name and PyPI project are named "PyDelphin", but the Python module and shell command are just delphin. PEP-423 recommends using the same name for both (the PEP's status is "deferred", though it's still good advice; also see #124, which is related to PEP-423). Some options:

1. There exists a separate (but apparently inactive) "delphin" project on PyPI. I could ask its author to take over that project URL and rename this project to "Delphin"

2. I could rename the module and command to pydelphin (e.g., from pydelphin.interfaces import ace) for the v1.0.0 version

3. I could do nothing (i.e., ignore PEP-423's advice)

I prefer (2) over (1), especially since v1.0.0 will break some backward compatibility anyway, but (3) wouldn't be the worst thing, either. (1) seems like it would increase some confusion, since the name is not audibly distinct from DELPH-IN.

[fcbond]

I have a slight preference for the shorter (1) --- two characters saved is two characters saved, then (3), the (2).

…

On Thu, Sep 27, 2018 at 8:57 AM Michael Wayne Goodman < ***@***.***> wrote: This issue is a request for user input. The package name and PyPI project are named "PyDelphin", but the Python module and shell command are just delphin. PEP-423 recommends using the same name for both <https://www.python.org/dev/peps/pep-0423/#id87> (the PEP's status is "deferred", though it's still good advice; also see #124 <#124>, which is related to PEP-423). Some options: 1. There exists a separate (but apparently inactive) "delphin" project on PyPI. I could ask its author to take over that project URL and rename this project to "Delphin" 2. I could rename the module and command to pydelphin (e.g., from pydelphin.interfaces import ace) for the v1.0.0 version 3. I could do nothing (i.e., ignore PEP-423's advice) I prefer (2) over (1), especially since v1.0.0 will break some backward compatibility anyway, but (3) wouldn't be the worst thing, either. (1) seems like it would increase some confusion, since the name is not audibly distinct from DELPH-IN. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#182>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD8xoxDm0ecYidsmumESAH3XjffAZHTks5ufCJrgaJpZM4W7upo> .

-- Francis Bond <http://www3.ntu.edu.sg/home/fcbond/> Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

Thanks for the feedback. I'm actually disinclined to use (1). Saving two characters is not a good enough reason to rebrand the whole project. PyDelphin is referenced in a dozen or so publications now, so changing the name would be confusing (for this and also the reason mentioned in the issue description).

I'll consider going with (3) over (2), since that would reduce the amount of code needing to be updated.

[goodmami]

After more thought, there's a way to use (1) without rebranding. I could use namespace packages such that some subset of the packages (delphin.mrs, delphin.itsdb, etc.) could be separate projects under the same delphin namespace, and PyDelphin is then a "meta-package" that pulls together the core components. This could also allow optional extensions, e.g., bottlenose could be remade into delphin.bottlenose (or delphin.httpserver to be a more descriptive, if less interesting, name).

A negative point is that this increases the complexity of the packaging, a burden I might not want to impose upon future maintainers.

[fcbond]

If (as I believe it does) bottlenose really relies on pydelphin then it is nice to have them packaged together, ...

…

On Thu, Oct 11, 2018 at 7:55 AM Michael Wayne Goodman < ***@***.***> wrote: After more thought, there's a way to use (1) without rebranding. I could use namespace packages <https://packaging.python.org/guides/packaging-namespace-packages/> such that some subset of the packages (delphin.mrs, delphin.itsdb, etc.) could be separate projects under the same delphin namespace, and PyDelphin is then a "meta-package" that pulls together the core components. This could also allow optional extensions, e.g., bottlenose <https://github.com/delph-in/bottlenose> could be remade into delphin.bottlenose (or delphin.httpserver to be a more descriptive, if less interesting, name). A negative point is that this increases the complexity of the packaging, a burden I might not want to impose upon future maintainers. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#182 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD8xt1jn3dVshk_EIo6syJrqf7CNEUXks5ujojrgaJpZM4W7upo> .

-- Francis Bond <http://www3.ntu.edu.sg/home/fcbond/> Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

Yes it builds directly on PyDelphin. Also gtest could be treated similarly. But note that this proposal doesn't package them together, but put them under the same namespace. So you'd do:

pip install pydelphin  # which installs delphin, delphin.mrs, delphin.itsdb, etc.
pip install delphin.bottlenose

Then you could do:

from delphin import bottlenose

This way, something like delphin.dmrs could be maintained by, e.g., Cambridge (if we could merge pydmrs in).

[goodmami]

Ok, we have control of the 'delphin' project on PyPI now. I'm still debating if the benefits of moving to namespace packages outweigh the increased complexity. For instance, it's easier to introduce plugin-like modules (e.g. #193) and to allow others to have maintainership over smaller parts of PyDelphin, but we'll then have many separate packages (each with their own README, setup.py, issues, versions, etc.)

I was thinking an alternative is to push PyDelphin to both the 'pydelphin' and 'delphin' projects on PyPI, but I think that will cause headaches. If one does pip install pydelphin and then pip install delphin, it will probably download both. So one might wonder why pip install --upgrade delphin is not getting the latest version (it is, but because pydelphin is still installed it blocks the other from being used). So if we move to the delphin project, the pydelphin one should be marked as inactive.

[goodmami]

This issue is now superseded by #222.