pyrad package name collision with a RADIUS client by github user 'wichert'

[xguse]

So I am putting together a pyrad conda package recipe and planning to host it via anaconda.org for folks to easily install via conda.

However, just like in PyPI there is already a package named pyrad that does something entirely different. I do not think that changing the program's proper name is even a remotely good idea. However, adding a specifier to the 'distribution name' might make sense. By distribution name, I simply mean what it would be referenced as on the database. Something like pyrad-seq would still be returned when a search for pyrad is run and it would allow the software to be served on PyPI and anaconda.org etc.

Currently a search of the PyPI for pyrad returns:

$ pip search pyrad
pyradau13      - Python wrapper around the Hairer/Wanner implementation of the RADAU13 ODE solver
PyRadbas       - Simple Radial Basis Function Networks in Python
pyradar        - Collection of algortihms and tools for manipulate satellite images
pyradio        - Command line internet radio player.
pyradex        - Python-RADEX
pyrad          - RADIUS tools
pyradi         - The PyRadi toolkit provides utilities for radiometry (flux flow) calculations, supporting electro-optical and infrared system
                 design.
pyradiodns     - A Python port of phpradiodns.
pyRadKDE       - a wheel type command interface for KDE, inspired by Kommando (KDE 3) and Neverwinternights.

Similarly, a search of anaconda.org yields:

$ anaconda search -t conda pyrad
Using binstar api site https://api.anaconda.org
Run 'anaconda show <USER/PACKAGE>' to get more details:
Packages:
     Name                      |  Version | Package Types   | Platforms
     ------------------------- |   ------ | --------------- | ---------------
     auto/pyrad                |      2.0 | conda           | linux-64, linux-32
                                          : https://github.com/wichert/pyrad
     auto/pyradbas             |    0.1.0 | conda           | linux-64
                                          : http://cybercase.github.com/pyradbas/
     auto/pyradio              |    0.5.2 | conda           | linux-64
                                          : http://github.com/coderholic/pyradio
     auto/pyradiodns           |      0.1 | conda           | linux-64
                                          : http://github.com/radiodns/pyradiodns
     hargup/pyrad              |          | conda           | linux-64
                                          : RADIUS tools
Found 5 packages

A package named pyrad shows up in both cases.

I am curious about your thoughts. For me personally, its not a big deal because I can/and do simply build it from the repo. But it may be an issue that presents a barrier to some potential users. Just thought I would bring it to your attention in case it had escaped your notice.

Thanks again for pyrad!

Gus

[dereneaton]

Hey Gus, I've been thinking a lot about this as well. And my thoughts relate to the versioning issue you raised also. I will push the current git version as 3.0.6 (though I fudged the versioning by calling the last one 3.0.51). It will probably be followed shortly by the branch currently called pyrad_depths, which adds some new features, and will eventually be 3.1.

Meanwhile, I've been working on a separate branch (not online yet) in which I'm rewriting pyrad to work as a legitimate Python module, though it will still have a command line interface generated with setuptools. Thus there will be a command line tool like always, but also set of Class objects and functions that can be used in interactive analyses in IPython. I see this as being the best way to make and save reproducible workflows for complex analyses that combine multiple data sets and change parameters throughout. This new version will also probably use h5py as a new dependency, maybe others. It's pretty much a complete re-write of pyrad.

As for naming with pip or conda, the new interactive version will be called ipyrad, which would avoid name conflicts and allow a pip or conda install. Because of the major changes, I'm leaning towards putting this up as a separate repo. The new version will require a few more dependencies, so branching seems like a good idea in order to keep the original pyrad as a more bare-bones alternative. The first ipyrad push is probably a few weeks away still, though.

[StuntsPT]

+1 for new repo if we're in for a total rewrite. The non-conflicting name would be a plus, and it would allow you to keep the "old" version in "maintenance mode" without branching. Just my 0.50€. =-)

[xguse]

I agree that a new repo makes the most sense for a major re-write. Its cleanest and will surely make maintaining/bug-fixes much easier on the original.