[Discussion] Splitting in-project libraries into external libraries

[CRImier]

Currently, ZPUI contains helper libraries for system-related tasks, namely:

• systemctl library
• wpa_cli library
• "ip addr" library
• tvservice library
• lsusb library

Questions:

• Would it be beneficial to split them into separate libraries, installable from PyPi?

Possible benefits:

• Allow reuse of libraries in other apps, as well as other projects
  • Will be pretty much required after #5 is done

Notes:

• All these libraries are subprocess-based, calling system utilities and parsing their output.
• These libraries would also need to be documented in some way - so that the split can actually benefit open-source community

[CRImier]

I think that a good first step will be to bring out these libraries into the libs/ folder in ZPUI root, splitting them from the applications themselves - at least this way other apps can use these libraries easily.

[j340m3]

I would advocate for splitting the libraries from each other so that they can develop at their own speed and other projects may profit, too. This is a huge advantage in my opinion. How would you perform the split? I would go for creating a repo for each library and uploading it separately to pypi.

The huge drawback would be here that it is massive organizational workload. In reference to #104, travis-ci is also able to automagically upload passed builds to pypi. So, with the right restrictions, we could give more possibilities to the crowd.

To be clear about the aforementioned restrictions:

• only master will be pushed to pypi (for obvious reasons)
• the unit-tests must run through
• the test coverage has to be at least as good as before
• [Optional] In order to merge into the master, the branch has to be approved (by you or by a certain amount of users)

[CRImier]

Yeah, it's quite a workload, and it doesn't bring any benefit to the project just yet - that's why it's an open issue (for somebody to pick up along the way) and not something I'm working on personally. It's cool that travis can do that - I'm wondering, could it do it if we store the libraries in libs/ and not in a separate repo?

[j340m3]

We could do that, but I never figured out how to tell travis to pack multiple packages and upload them seperatly. Picking up along the way may cost a lot, if each gets an extra repo, since when more people develop, you need to force a stop to make the transition. Now the developer base is low and the development kinda small (no offense).

[CRImier]

I mean, when a library moves from ZPUI libs/ to a separate package, all we need to change in ZPUI is some import statements (not even necessarily, we can import that lib in libs/__init__.py) and add a line in requirements.txt, is there something I'm missing that would make the transition harder? Unless, of course, there's multiple people improving that library at the same time, which I don't find likely even when more developers join this project =) (no offense taken, this is a fact)

[j340m3]

Ok. I was thinking of the latter case. But if you don't think that to be likely, then it's not that urgent.

An extra workload what I see is that you maybe want also have automated checks and upload to pypi over there in the new repo. The time to set this up blocks the development of this library.

[CRImier]

Ah, I see. Well, shouldn't be more than 1-2h of development downtime either way =)

[j340m3]

That's more like the best case. My first time trying this, it took me over a week to fix the majority of the errors. I would be more careful about that.

[CRImier]

Well, you don't need to add the library to requirements.txt and switch the imports until it's publishable, I think, and there's the test PyPi repo for any experimentation you might want to do

[j340m3]

True. I was also always creating a repo from scratch and wasn't migrating. Should be easier. Nevermind my thoughtlessness. Also: Easy Splitting without taking it out of libs/

[CRImier]

lsusb library now moved into libs/, will also be used by the "Hardware test" app soon.