Package naming policies

[ocefpaf]

My 2-cents:

1. First try the package original name 😁
   A possible conflict would be packages like beautifulsoup4 (pypi) and beautiful-soup (anaconda name). I strongly believe that the majority of the users cannot find the anaconda package in a CLI search and end up installing the PyPI version.
2. When conflicts arise, like a c-lib and its python bindings with the same name, add a py<c-libname>. For example: cdo and pycdo. (Or maybe python-cdo?)
3. When adding a new package that has libraries used by other packages avoid naming it lib<package name>.

Note that anaconda names the netcdf package libnetcdf. However, that package is more than just the netcdf libs. Same for gdal and libdal, but in that case gdal is even more confusing because that is the python bindings only, and the libdal is the rest of the package. To me this behavior is a bad mix of the Linux world, that splits packages into lib, dev, headers, etc and the python bias that we have when packaging non-python packages.

(See the issues raised on #16.)

[ocefpaf]

Question: both pip and conda are case insensitive, but PyPI allows for mixed case names on the web. Should we do as anaconda does and keep everything lower case?

[ocefpaf]

Question: How to resolve a package name dispute (to avoid name squatters)?

If a discussion cannot resolve the naming we should stick with rule (1).

[jankatins]

First try the package original name

Only for python, for r use r-<cran name>

At some point, there will also be subpackages naming (e.g. matplotlib and matplotlib-qt4.

Should we do as anaconda does and keep everything lower case?

My vote: All lower...

[pelson]

Thanks guys. Great start! @ocefpaf - is there an oracle somewhere in the Deb/Fed world on this kind of thing. If I'm honest, I'd personally prefer to follow their naming convention than Anaconda's...

Everything you've said so far makes a lot of sense to me. At the risk of pulling in too many chefs for Github's linear issues (at which point we should probably drop out to the conda-forge mailing list), I'd love to hear the opinions of @ericdill, @rmcgibbo and @mwcraig (and anybody else with experience in this realm).

[jankatins]

debian: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

Package names (both source and binary, see Package, Section 5.6.7) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character.

There is also the python policy: https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names

Public modules used by other packages must have their binary package name prefixed with python-. It is recommended to use this prefix for all packages with public modules as they may be used by other packages in the future. Python 3 modules must be in a separate binary package prefixed with python3- to preserve run time separation between python and python3. The binary package for module foo should preferably be named python-foo, if the module name allows, but this is not required if the binary package ships multiple modules. In the latter case the maintainer chooses the name of the module which represents the package the most. For subpackages such as foo.bar, the recommendation is to name the binary packages python-foo.bar and python3-foo.bar.

[ChrisBarker-NOAA]

@JanSchulz posted:
"consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character."

seems reasonable, let's just adopt it.

Python packages should mirror the name on pypi whenever possible, and the actual python package name if there is no py_py name.

[no idea why continuum did what it did with beautiful soup, but what can we do?)

Python bindings to a c lib should be called py_the_lib_name, unless it already has another name on pypi.

c libs should be called lib[the lib name]

• continuum is pretty inconsistent on this, though:
  • libpng
  • jpeg
  • freetype
  • libtiff

And Hey! I just noticed that we're maintaining a "beutifulsoup4" package -- making @ocefpaf 's point!

As for GDAL -- that's a mess -- it's great that the GDAL project provided python bindings, but having them built and installed at at once has been a pain for ages (and not just with conda) And continuum has now split them off, which is good, but they are stuck with the old naming (bad). So let's try not to do that. There are times when multiple things are in one source repo that really should be multiple packages -- so let's keep it that way when we can.

We should put this in a doc somewhere, that we can all edit, rather than this linear discussion...

In the end, "A foolish consistency is the hobgoblin of little minds" -- so let's establish some default standards, and then not get too uptight about it.

[pelson]

In the end, "A foolish consistency is the hobgoblin of little minds" -- so let's establish some default standards, and then not get too uptight about it.

👍 for that. Who doesn't have access to the wiki on this repo that would like it? That would seem an obvious first place for the content.

[jankatins]

I would be very much for a md document in this repo which gets built into the website. PRs and the possibility to comment and repush are IMO better than wiki style changes...

[ChrisBarker-NOAA]

@JanSchulz: yeah the end goal is probably user-readable docs, so that's a good idea. However, right now the .io site is static html -- is is possible to mix that with Jekyll (Or sphinx?)?

If the longer term goal is a Jekyll site, then starting with .md in the wiki is not so bad....

[jankatins]

@ChrisBarker-NOAA My (limited but usually bad) experience with discussion around wiki docs tells me to go with a simple md doc in the repo and simply link to the repo from the html files :-) Comments are much better here...

[jankatins]

"conda name = pypi name" is also great for this:

{% set data = load_setuptools() %}

requirements:
  build:
    - python
    {% for req in data.get('install_requires', []) -%}
    - {{req}}
    {% endfor %}

[jankatins]

[BTW, it would be really great if conda had a way to submit the pip names and get conda names back...]

[ChrisBarker-NOAA]

I'm not sure what you mean here -- could you clarify?

On Feb 13, 2016, at 4:21 AM, Jan Schulz notifications@github.com wrote:

[BTW, it would be really great if conda had a way to submit the pip names
and get conda names back...]

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[jankatins]

@ChrisBarker-NOAA I'm no sure how many packages do have different names than the original pypi package, but there is probably are a few. If tehre would be a function which returned the pip package names as conda package names, then specifying the package dependencies could be as simple as

requirements:
  build:
    - python
    {% for req in translate_to_conda(data.get('install_requires', [])) -%}
    - {{req}}
    {% endfor %}

Or even easier:

requirements:
  build:
    - python
    - {{ TRANSLATED_SETUPPY_REQUIREMENTS}}

...but I should probably take this to the conda-build repo...