-
Notifications
You must be signed in to change notification settings - Fork 22
[request] additional properties for 'track.json' and 'modules.json' #7
Comments
I think it is necessary, MRepo also needs it. |
An answering par of my questions myself: additional files in a module's subdir remain untouched. Just not sure how Fields which would come in handy as well include |
|
So especially, those fields will ot be removed when you rewrite the file?
👍
Ouch, a copy-pasta-error – thanks for the hint! Fixed. Good thing I didn't yet publicly announce it 🙈 |
You might wish to check the preview again: I finally completed the "backend class" to make access compatible to the one used by my F-Droid repo. Now one can sort and filter 😃 While doing that I noticed which other details would be nice to have. In addition to above mentioned
In
With those available I could also offer to include other repos with my web front-end, as I do for F-Droid repos – so you could have a WebIF for yours as well. Further it could be nice to have a "full description" (in addition to the summary now set up as "description") to offer more details – which could e.g. be included with |
Btw: do you have an account on the Fediverse somewhere (Mastodon, Misskey, Lemmy, Friendica …)? I'm preparing for go-live of my MM-repo, see my first poll on the topic here 😉 When lifting the cover, I plan also to promote MRepo. So if you have a Fedi-acccount, it would be natural for me to mention that. |
Here's an example ("summing-up") of useful fields that (with the exception of {
"web": "https://example.org/",
"source": "https://github.com/johndoe/mod_magisk",
"tracker": "https://github.com/johndoe/mod_magisk/issues",
"translation": "https://example.crowdin.com/translate",
"donation": "https://example.org/donation",
"category": "Internet",
"antiFeatures": ["NonFreeDep","NonFreeAssets"],
"max_num": 2
}
Which fields you feel to make optional (i.e. can be empty or even missing altogether) I fully leave up to you. I see that with the fields already present, you prefer them to be there even if empty (see e.g. |
Gladly – and can't wait to see it happen 😃 Please give me a ping here for when things become available in repo-util (especially with |
It' s Ok
It seems that few modules provide something like Crowdin to help localization, if the module is used as an extension of the app, it is possible, but this is indeed rare, so we don't need it, and we still have web, source, tracker.
I think MRepo needs its own category, but I'm not sure how to do that, it's up for discussion then create a |
Translation:
At least one of them is in my repo already, yes. I find it useful as it animates users to contribute. But as said, no strong feelings, so I leave the decision to you. Categories: in F-Droid, an app can have 1..n categories assigned (1 is mandatory, additional ones are optional). Most Magisk modules would just have "System", true, just a few match things like "Internet" (like the proxy module in my repo). But it cannot hurt to be prepared, making it AntiFeatures: Yes, the F-Droid definition uses string identifiers (CamelCased, no spaces allowed). See the names in the linked list. Examples: NonFreeDep (depends on non-free things like GSF being present), NonFreeNet (depends on a non-free network service). You can pick my |
As it seems it will take a little while until you implement this, can we already agree on the structure & fields used – so I can (partly) prepare on my end? Especially:
If the time-gap becomes too large, I might forget what "work-arounds" I placed with what in mind – so I need to comment them accordingly for later replacement when structures are implemented here 😉 So as per my above comment, can you already say how it will look like in |
Due to personal reasons, I can't deal with these problems in time, I should start to solve these issues soon. |
Thanks! No pressure meant, just asking for orientation so I can properly prepare things on my end. Once clean, I'll also make my part public under a F/LOSS license with reference to repo-util here, so you can count it a "complementary module" 😉 So once you know, a note will be very welcome (even if implementation is still ongoing then). |
New track.json{
"id": "zygisk_lsposed",
"update_to": "https://lsposed.github.io/LSPosed/release/zygisk.json",
"license": "GPL-3.0",
"website": "https://lsposed.org/",
"source": "https://github.com/LSPosed/LSPosed.git",
"tracker": "https://github.com/LSPosed/LSPosed/issues",
"donate": "",
"added": 1679025505.129431,
"last_update": 1673882223.0,
"versions": 1
} New modules.json{
"name": "Sanmer Magisk Repo",
"metadata": {
"version": 1,
"timestamp": 1690465277.11947
},
"modules": [
{
"id": "zygisk_lsposed",
"name": "Zygisk - LSPosed",
"version": "v1.8.6 (6712)",
"versionCode": 6712,
"author": "LSPosed Developers",
"description": "Another enhanced implementation of Xposed Framework. Supports Android 8.1 ~ 13. Requires Magisk 24.0+ and Zygisk enabled.",
"latest": {
"zipUrl": "https://ya0211.github.io/magisk-modules-repo/modules/zygisk_lsposed/v1.8.6_(6712)_6712.zip",
"changelog": "https://ya0211.github.io/magisk-modules-repo/modules/zygisk_lsposed/v1.8.6_(6712)_6712.md"
},
"versions": [
{
"timestamp": 1673882223.0,
"version": "v1.8.6 (6712)",
"versionCode": 6712,
"zipUrl": "https://ya0211.github.io/magisk-modules-repo/modules/zygisk_lsposed/v1.8.6_(6712)_6712.zip",
"changelog": "https://ya0211.github.io/magisk-modules-repo/modules/zygisk_lsposed/v1.8.6_(6712)_6712.md"
}
],
"track": {
"type": "ONLINE_JSON",
"license": "GPL-3.0",
"website": "https://lsposed.org/",
"source": "https://github.com/LSPosed/LSPosed.git",
"tracker": "https://github.com/LSPosed/LSPosed/issues",
"donate": "",
"added": 1679025505.129431
}
}
]
} |
So you do not want to include And no per module But apart from that: good to have most of the "core data" in the |
|
Ah 😄 Good.
Maybe just having the fields in the JSON already (per module, and also in the index), postponing implementation in the app until decided? I could then cleanup (and finally publish) my corresponding website libraries, which currently still rely on some "dirty hacks" as those fields are not yet available "officially". If you agree, I think best is making both arrays/lists (more future-proof). |
Adding antifeatures and categories fields is simple, the problem is how to classify the modules. |
I can help you with that, it's done in my repo already. Examples for antifeatures you can even see with the web browser already (thanks to my "dirty hacks"), simply filter by "AntiFeatures: yes" and then mouse-over the reddish circles next to the module name. You can also filter by category, though due to the details pages still missing (was waiting to have all the data ready first in the index) it's not yet displayed. If you want to take a look at the index I currently construct (in addition to the If you specify what problems you have with classification, I can try answering your questions. I guess it's towards the antifeatures; you can refer to my F-Droid repo for that. I have a JSON with their definitions available, that should give you an idea here. |
At present, the I will continue to promote the development of MRepo. During this period, there may be some changes in the json structure. |
So I still cannot publish my library as it will still depend on "local hacks" 😢
While all this is in motion, I guess it's better I do not update my local branch. Please let me know when things settled and I should give it a try. It would then help to know what changes have been done, so I can adjust my library accordingly. Thanks! |
@ya0211 may I kindly ask you not to entirely break the entire thing on such a short notice (and that even only afterwards) again? There were just 14 days between you stating structures are "in flux" ("During this period, there may be some changes in the json structure" on August 5th), and then releasing a new version of MRepo which drops compatibility (August 19th) without any warning ahead, causing a lot of inconveniences for maintainers as well as users of other repositories. I originally had planned to be on vacation since last Friday; in that case things would have stayed broken for 2 more weeks. This is not what I'd call "expected behavior"; not even release notes were giving a hint. Such major steps should be communicated better (especially when explicitly asked for). Apart from that "big mishap": that was a lot of work on your end, too – thanks for integrating so many of my wishes with the new version! I still need to see that I update the framework on my end to make use of all that, but what I discovered so far looks great. |
Can we have a
website
property intrack.json
, to link to the module's website for further information? A property to point to the module's issue tracker would also be nice. Both properties should be optional, or at least allow for empty values when a corresponding URL is not available.In this context: how would the util deal with
track.json
which it doesn't know itself (e.g. acomment
property)Would they simply be ignored – or would they be removed? I might need some"control data" for automation/maintenance tasks not covered by repo-util and think about where to place them.
EDIT: details of the requested properties in this comment below.
The text was updated successfully, but these errors were encountered: