Make package names and namespaces part of the spec.

[dlech]

Picking up the conversation from #129 (comment)...

@rhempel said:

I think that we may need to be a little more protective of ev3dev as a standalone word or package name. In my mind ev3dev is the term we are using for the entire distribution - and it's a little wierd running ev3dev on other platforms, but the intent is to support LEGO compatible shields on those platforms.

So I'd prefer if you named your binding ev3dev-csharp or something like that - whatever you like - but please not just ev3dev by itself to avoid confusion.

Anyone else have any comments for or against?

[rhempel]

I think this is a good idea - so are you suggesting something in spec.json - an entry for each binding with:

• language
• package name
• repo location on github
• package location(s) on the package hosting site for the language

Any other keys that might be handy?

[dlech]

I totally agree that ev3dev by itself should no be used for package names or namespaces. Furthermore, I think you should make package names and namespaces part of the ev3dev-lang spec.

Here are my thoughts on naming conventions.

• GitHub repository names for languages should be of the format ev3dev-lang-<language>. Example: ev3dev-lang-python, ev3dev-lang-dotnet, etc.
• Package names (as in packages published on PyPi, NuGet, etc. - NOT debian packages) should not include the name of the language because that is redundant. It should simply be ev3dev-lang.
• Debian package names will follow debian policy. Examples: python, Mono, etc.
• Namespace for anything implementing the ev3dev-lang spec should be Ev3devLang.

[dlech]

So, to use ev3dev-lang-python as an example, the ev3dev folder should be renamed to ev3dev-lang since that becomes the module name. Also, the package name in setup.py should be renamed to ev3dev-lang.

[rhempel]

Ack that will make it into the next spin of the module - we'll be adding the static button state hopefully :-)