abderrahim commented on code in PR #1890:
URL: https://github.com/apache/buildstream/pull/1890#discussion_r1526427770


##########
tests/frontend/mirror.py:
##########
@@ -807,3 +807,93 @@ def test_mirror_expand_project_and_toplevel_root(cli, 
tmpdir):
         # Success if the expanded %{project-root} is found
         assert foo_str in contents
         assert bar_str in contents
+
+
+# Test a simple SourceMirror implementation which reads
+# plugin configuration and behaves in the same way as default
+# mirrors but using data in the plugin configuration instead.
+#
[email protected](DATA_DIR)
[email protected]("datafiles")
+def test_source_mirror_plugin(cli, tmpdir):
+    output_file = os.path.join(str(tmpdir), "output.txt")
+    project_dir = str(tmpdir)
+    element_dir = os.path.join(project_dir, "elements")
+    os.makedirs(element_dir, exist_ok=True)
+    element_name = "test.bst"
+    element_path = os.path.join(element_dir, element_name)
+    element = generate_element(output_file)
+    _yaml.roundtrip_dump(element, element_path)
+
+    project_file = os.path.join(project_dir, "project.conf")
+    project = {
+        "name": "test",
+        "min-version": "2.0",
+        "element-path": "elements",
+        "aliases": {
+            "foo": "FOO/",
+            "bar": "BAR/",
+        },
+        "mirrors": [
+            {
+                "name": "middle-earth",
+                "kind": "mirror",
+                "aliases": {
+                    "foo": ["<invalid>"],

Review Comment:
   Just to be clear, this discussion is supposed to be on 
https://github.com/apache/buildstream/pull/1890#discussion_r1509989058 (I hope 
you are replying to that, and not to this which is simply pointing out the 
"weird source mirror plugins"). I've tried to reply earlier, but my comment was 
detached from this discussion by a github bug 
(https://github.com/apache/buildstream/pull/1890#discussion_r1523626484).
   
   Anyway, my point is that by forcing plugins to have aliases defined in a 
specific way, they end up doing weird things to try to work around it. For 
instance, take my `gitlab_lfs_mirror` plugin from 
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/18099. I am 
doing
   
   ```
   - name: freedesktop-sdk-raw-file-mirrors
     kind: gitlab_lfs_mirror
     config:
       url: https://gitlab.com/
       project: freedesktop-sdk/mirrors/{alias}/raw-files
     aliases:
       cpan: [invalid]
       crates: [invalid]
       ftp_gnu_org: [invalid]
       github_files: [invalid]
       oasis_open_xml: [invalid]
       pagure_releases: [invalid]
       pypi: [invalid]
       sourceforge: [invalid]
       sourceforge_download: [invalid]
       sourceware_pub: [invalid]
       tar_https: [invalid]
   ```
   
   I'd like to be able to do
   ```
   - name: freedesktop-sdk-raw-file-mirrors
     kind: gitlab_lfs_mirror
     config:
       url: https://gitlab.com/
       project: freedesktop-sdk/mirrors/{alias}/raw-files
       aliases:
       - cpan
       - crates
       - ftp_gnu_org
       - github_files
       - oasis_open_xml
       - pagure_releases
       - pypi
       - sourceforge
       - sourceforge_download
       - sourceware_pub
       - tar_https
   ```
   
   Or better yet, dropping the `config:`
   
   ```
   - name: freedesktop-sdk-raw-file-mirrors
     kind: gitlab_lfs_mirror
     url: https://gitlab.com/
     project: freedesktop-sdk/mirrors/{alias}/raw-files
     aliases:
     - cpan
     - crates
     - ftp_gnu_org
     - github_files
     - oasis_open_xml
     - pagure_releases
     - pypi
     - sourceforge
     - sourceforge_download
     - sourceware_pub
     - tar_https
   ```
   
   Ultimately, the plugin only needs to tell the core the aliases that it can 
handle and optionally how many URLs it can provide for a given alias. 
Otherwise, it should be free to define its configuration in the way that makes 
most sense to what it is doing.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to