Should downstream packaging include importers? about cotp HOT 4 CLOSED

I think that for now we could choose the first option, but would be temporary.

I would plan to code split the project and create to separate CLIs:

• cotp.
• The second would be the importer which contains the importing logic, the rewritten ones from python and the existing ones in cotp.
• One shared library

This would permit:

1. Better code splitting from my side
2. Smaller binary size of cotp
3. Simple logic from your side, two rust packages without optional dependencies, random python scripts and so on

Let me know your thoughts.

from cotp.

Lets go for a hybrid: direct to option 2 but "temporarily" as the contents of the second package will shift dramatically as you split up the actual upstream organization.

I wouldn't care at all if the converters logic was actually done in rust or python ... the latter option might even be easier to spin up importers for various systems that have Python libraries available. I would just organize it all so there was a common CLI interface that loaded the correct converter script (via subcommand?). It could be a hybrid too.

from cotp.

Here is a version of testing version of a split package: cotp-converters. It can be installed directly without enabling the [testing] repository like this:

$ pacman -U https://archlinux.org/packages/extra/x86_64/cotp{,-converters}/download/

It isn't clear to me what Python modules are required for runtime. The requirements.txt file here seems to be mostly developer / deployment tooling, not run time dependencies. Can you comment on what additional Python stuff outside fo the stdlib is currently needed at runtime?

from cotp.

No external dependencies are required to run these python importers. I think that the requirements.txt file is misleading and will be removed in the next project refactor. Tried to install the cotp-converters package and I can see the scripts under my /usr folder 👍

from cotp.