[WIP] tuf-client as a standalone installation

[sechkova]

Fixes #1181

Description of the changes being introduced by the pull request:

This is a WIP trying to identify whether splitting the client and repository code and maintaining a client as
a separate installation (in a client branch for now) will be useful for client side users of tuf (e.g. pip) as well as for providing some kind of support for older versions.

Up to now I have only removed the pure repository code and generated a tuf-client distribution.
This only reduces the lines of code while the dependencies remain the same, since client and repository share all dependencies (see comment). Client even upgrades them with requests.

I added one dummy test simply calling updater.refresh without using the repository code.

Please give me your opinion on:

• Does this even make sense?
• Did I get the idea right?
• Is this bringing a significant value given the effort to rewrite the test suite?
• If all of the above is yes, should we continue with fixing all tests and the configuration?

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[sechkova]

In case I have successfully regenerated requirements-pinned.txt following the guidelines in requirements.txt, the resulting diff is only in version numbers:

diff --git a/requirements-pinned.txt b/requirements-pinned.txt
index 848e99a8..48e73a38 100644
--- a/requirements-pinned.txt
+++ b/requirements-pinned.txt
@@ -1,14 +1,14 @@
-certifi==2020.6.20       # via requests
+certifi==2020.11.8        # via requests
 cffi==1.14.3              # via cryptography, pynacl
 chardet==3.0.4            # via requests
-cryptography==3.2.1         # via securesystemslib
-enum34==1.1.6             ; python_version < '3' # via cryptography
-idna==2.10                 # via requests
-ipaddress==1.0.23         ; python_version < '3' # via cryptography
+cryptography==3.2.1       # via securesystemslib
+enum34==1.1.10            # via cryptography
+idna==2.10                # via requests
+ipaddress==1.0.23         # via cryptography
 pycparser==2.20           # via cffi
 pynacl==1.4.0             # via securesystemslib
-requests==2.25.0
-securesystemslib[crypto,pynacl]==0.18.0
-six==1.15.0
-subprocess32==3.5.4       ; python_version < '3' # via securesystemslib
+requests==2.25.0          # via -r requirements.txt
+securesystemslib[crypto,pynacl]==0.18.0  # via -r requirements.txt
+six==1.15.0               # via -r requirements.txt, cryptography, pynacl, securesystemslib
+subprocess32==3.5.4       # via securesystemslib
 urllib3==1.26.2           # via requests

[joshuagl]

Thank you for taking a stab at this @sechkova! 🎉

My motivation for filing #1181 was the idea that an effort such as this might be useful:
a) for vendoring tuf into pip, to reduce the number of files and LOC added to that project (see pypa/pip#9041)
b) for theoretically providing an as small as possible base for interested parties to pick up if they want/need to continue to use tuf/client/updater.py on a version of the interpreter that will no longer be supported following the refactor towards 1.0 (i.e. 2.7)

I'll leave others to comment on whether they feel this work is worthwhile cc @lukpueh @trishankatdatadog @jku

[joshuagl]

Might as well scrap this, too. It's not useful for clients using updater.py

[joshuagl]

I don't think we want/need this if we're not using repository_tool?

[sechkova]

Change of heart!
@jku gave us convincing arguments about grouping repository/client/common code in a proper directory structure and packaging two separate repository/client distributions all in the current development branch.

I think this suggestion achieves the goals listed by Joshua:

My motivation for filing #1181 was the idea that an effort such as this might be useful:
a) for vendoring tuf into pip, to reduce the number of files and LOC added to that project (see pypa/pip#9041)
b) for theoretically providing an as small as possible base for interested parties to pick up if they want/need to continue to use tuf/client/updater.py on a version of the interpreter that will no longer be supported following the refactor towards 1.0 (i.e. 2.7)

while in addition:

• no need to rewrite a big part of the test cases
• no need to maintain common code in two places

As a drawback, one repository will host configuration for two packages. We can use the occasion to experiment with "modern packaging" #1161, however.

[sechkova]

In case there are no objections on the proposal in the last comment, I will close this PR and reopen another one with the suggested approach.

[jku]

Closing this based on last comment :)