Proper packaging about caringcaribou

[kasperkarlsson]

This might be a useful guide for certain types of scenarios, but simply linking a blog post without any explanation or motivation as a GitHub issue is quite unlikely to lead to major changes.

I have read through the post. Signing up for various third-party services (which I have no idea if they are useful for CAN communication, for example) and adding multiple dependencies (such as flit, black, coverage, flake8, mccabe, mypy, pylint, pytest and tox) seems to add limited value here. If you would like to share your thoughts on how this is applicable and useful for Caring Caribou, please let us know. Otherwise this issue will be closed.

[brainstorm]

I think it's about having a systems and UX mindset to see the value of implementing what the blogpost proposes.

For instance, I know folks that have had difficulties installing and operating your package. Implementing what's described in the blog will completely eliminate that problem because installing your package becomes as familiar as the C UNIX dance:

tar xvfz package.tgz && ./configure && make && make install

Or having a similar view on automotive context: having the correct connectors between modules in a car facilitates installation and interoperability, right?... or do you just peel and solder cables?

Deviating from the norm, in this case for python packaging, generates all sorts of integration and usability issues.

Just my 2 cents ;)

[kasperkarlsson]

Getting on pip could be a great thing (and this has indeed been discussed before), but any development requires both time and resources which are not currently available.

However, I am not sure how that could help configure the system for physical/virtual CAN interfaces or in creating the ~/.canrc configuration file (by following https://github.com/CaringCaribou/caringcaribou/blob/master/documentation/howtoinstall.md ). These are the most common problems I know of - do you know any other issues (e.g. related to downloading the code)?

[brainstorm]

There are many issues with naming and structure that are not considered a standard way to structure a python project.

For instance, caringcaribou should not have a tool subfolder, but caringcaribou again (standard python). Other examples are lib and modules... they shouldn't be there nor named as they do. See the following python project for a good example on structure and CLI design (other than the blogpost).

https://github.com/ewels/MultiQC

But you are probably right, at this point the amount of refactoring needed to comply with normal python project structure might be tedious (but not too long/tricky actually).