Closed alerque closed 8 months ago
I would plan to code split the project and create to separate CLIs:
This would permit:
Let me know your thoughts.
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.
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?
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 :+1:
As I picked up
cotp
in Arch Linux packaging I got to thinking about the usage instructions, and I think it might be good to ship some of the importers somewhere (e.g./usr/share/cotp/improters
or something), add the necessary python stuff as opt-depends, and have some sort of indication in the docs how to run this. Or perhaps this should be a split packagecotp-importers
with all the dependencies included and a wrapper script that makes it easy to locate all the import scripts.Thoughts?