It'd be helpful to publish delphi to PyPI

[anthonyduong9]

It'd be helpful to publish delphi to PyPI, since PyPI is the place to host an open source Python module and makes it easy for developers to find and install it (instead of needing to clone the Git repo). It'd be even more helpful to determine the next version number and publish, automatically, by using this in CI.

[anthonyduong9]

If this is ok, I can start working on it.

[SrGonao]

Delphi seems to be already taken, so we would either have to do delphi-{something} or something else (like seeing if the other package is still in use). I'm not sure if I have a good idea on what the {something} should be, interpretability maybe, @norabelrose, @luciaquirke?

Apart from naming, what else would you need to do to add it to PyPI?

[luciaquirke]

delphify
oracle-delphi
know-thyself

[luciaquirke]

delphic

adjective

1. relating to the ancient Greek oracle at Delphi.
2. deliberately obscure or ambiguous

[luciaquirke]

I like delphic, it is in a great tradition which includes calling an app for getting work done "slack" and an app for having fun with friends "discord"

[luciaquirke]

@anthonyduong9 please go ahead with the name delphic!

[hijohnnylin]

hello! chiming in here with a minor suggestion, feel free to ignore this:

checking if you intend on changing this repo name to delphic as well. if not, then we may end up with both pip install delphic but git clone [...]/delphi, which could possibly be a little confusing (though not a huge deal).

i don't have any great suggestions to resolve that, unfortunately. it may possibly be less work for you if the pypi package is something like eleutherai-delphi or eleuther-delphi etc, though it is a little more typing

[anthonyduong9]

I like the name eleutherai-delphi, and generally, the prefix eleutherai- for any package name that would otherwise not be unique. We already have to think of how to make another package name unique in EleutherAI/sparsify#76, and I could see there being more cases in the future (e.g. elk).

Somebody wrote an entire article about our kind of situation, and that's basically what they came up with.

[luciaquirke]

Yeah eai-delphi and eai-sparsify seem to make good brevity/clarity tradeoffs, let's do it. Thanks all 🙏

[anthonyduong9]

@luciaquirke I just found out there's already a package eleuther-elk on PyPI. See https://pypi.org/project/eleuther-elk/. So I think it'd be great to keep using the eleuther- prefix for consistency, plus make it easier for developers to find EleutherAI packages when they search "eleuther". Hopefully people rarely need to type the package name anyways.

[luciaquirke]

Good catch, we will rename the elk one at some point. Sticking with eai-delphi.

[anthonyduong9]

Thanks, sounds good.

[luciaquirke]

The sparsify version of this is working now, the main takeaways are:

• remove unused env from build.yml
• there may also be some default values in the pyproject.toml that can be removed, e.g. the 'conventional' commit parser
• update to new publish action uses: python-semantic-release/publish-action@main from deprecated alternative
• manual release first via twine, and then we can register github as a publisher in PyPI GUI (maybe get nora to do this)
• we are waiting on a community PyPI token but we can use a personal PyPI token for now and then transfer ownership later

the commit formats are

1. fix: in header for patch
2. feat: in header for minor
3. feature: in header and BREAKING CHANGE: in footer for major

[anthonyduong9]

I'm glad to see the releases and publishing working for the eai-sparsify package. Thanks for summarizing and sorry you had to make some of those fixes. I can incorporate your comment into a PR later today - hopefully this goes smoothly now that we've seen what works.

[luciaquirke]

no apologies necessary, thanks for working with us!!