|
|
Home » Developing U++ » U++ Developers corner » UppHub - new package registration (How do we want to solve this problem?)
UppHub - new package registration [message #56094] |
Sat, 23 January 2021 22:13 |
|
Klugier
Messages: 1082 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
Let's assume I created package "MyFirstUppHubPackage". What should be the process of registering it in global registry? Should it be done via pull request or we assume that we will add by adding appropriate message on the forum with UPPHUB_BEGIN and UPPHUB_END. What will happen in such case when site will be offline? We had several outages in the past, so the continuity can not be guarantee.
Backing to UppHub declaration:
{ "name": "URR",
"packages": [ "Urr" ],
"description": "Simple UDP Request-Response protocol",
"repository": "https://github.com/mirek-fidler/urr.git",
"status": "stable",
"category": "networking",
"readme": "https://raw.githubusercontent.com/mirek-fidler/urr/master/README.md"
}
Should this manifest be somehow provided in the source files, so it can be modified independently. Here is the modification:
UPPHUB_BEGIN
{
"nests": [
"https://raw.githubusercontent.com/mirek-fidler/Skylark/upp-hub/manifest.json",
]
}
UPPHUB_END
upp-hub is single branch with manifest file. Thanks to that, we will be able to connect packages that are not in global registry. I mean would be good to extend UppHub by "Add custom" and then passing the link " https://raw.githubusercontent.com/mirek-fidler/Skylark/upp-h ub/manifest.json". In such case it should be registered locally. Moreover, we will be able to add new "registry" package basing on simple PR (I suggest separate repository for it within ultimatepp organization). Mirror, host of this file is welcome just in case.
This is my concerns about current implementation. We need to be very caution here, because one selected pattern will stay with us for the very long time...
Klugier
U++ - one framework to rule them all.
[Updated on: Sat, 23 January 2021 22:36] Report message to a moderator
|
|
|
Re: UppHub - new package registration [message #56111 is a reply to message #56094] |
Wed, 27 January 2021 18:04 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Sat, 23 January 2021 22:13Hello,
Let's assume I created package "MyFirstUppHubPackage". What should be the process of registering it in global registry?
There will be list maintainer(s) responsible for editing these lists. This cannot be automated. Think of malware...
Quote:
Should it be done via pull request or we assume that we will add by adding appropriate message on the forum with UPPHUB_BEGIN and UPPHUB_END. What will happen in such case when site will be offline? We had several outages in the past, so the continuity can not be guarantee.
The list in the forum is temporary, mostly to test it is possible.
Quote:
Backing to UppHub declaration:
{ "name": "URR",
"packages": [ "Urr" ],
"description": "Simple UDP Request-Response protocol",
"repository": "https://github.com/mirek-fidler/urr.git",
"status": "stable",
"category": "networking",
"readme": "https://raw.githubusercontent.com/mirek-fidler/urr/master/README.md"
}
Should this manifest be somehow provided in the source files, so it can be modified independently.
Yes, something like that is already half-implemented.
Quote:
upp-hub is single branch with manifest file. Thanks to that, we will be able to connect packages that are not in global registry. I mean would be good to extend UppHub by "Add custom" and then passing the link " https://raw.githubusercontent.com/mirek-fidler/Skylark/upp-h ub/manifest.json". In such case it should be registered locally. Moreover, we will be able to add new "registry" package basing on simple PR (I suggest separate repository for it within ultimatepp organization). Mirror, host of this file is welcome just in case.
I am really concerned about making this automated. BTW, you can already use the list on your harddrive if you activate "Verbose" mode, there is a setting in UppHub dialog. This is mostly meant for testing though.
|
|
|
Re: UppHub - new package registration [message #56118 is a reply to message #56094] |
Thu, 28 January 2021 13:29 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Sat, 23 January 2021 22:13
{ "name": "URR",
"packages": [ "Urr" ],
"description": "Simple UDP Request-Response protocol",
"repository": "https://github.com/mirek-fidler/urr.git",
"status": "stable",
"category": "networking",
"readme": "https://raw.githubusercontent.com/mirek-fidler/urr/master/README.md"
}
Should this manifest be somehow provided in the source files, so it can be modified independently. Here is the modification:
UPPHUB_BEGIN
{
"nests": [
"https://raw.githubusercontent.com/mirek-fidler/Skylark/upp-hub/manifest.json",
]
}
UPPHUB_END
Check how Skylark is now linked:
https://www.ultimatepp.org/forums/index.php?t=msg&goto=5 5542&#msg_55542
|
|
|
|
|
Re: UppHub - new package registration [message #56146 is a reply to message #56130] |
Sun, 31 January 2021 23:37 |
Oblivion
Messages: 1112 Registered: August 2007
|
Senior Contributor |
|
|
By the way,
Do we really want to use seemingly arbitrary categories in the list? I am almost sure that those tags will be bloom after the takeoff, and we'll probably get redundant category tags like "GUI", "user-interface", etc.
Wouldn't it be better to aling the categories with upp's main directory structure, ie.a functional categorization, like "Core", "Core/Plugin", "CtrlLib", "Draw", "Examples" (users may want to provide more example code with documentation), "Application", etc.
Package readme, if provided, and short summary that appears on the list, already give the idea as to what the package does.
Best regards,
Oblivion
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Sun, 31 January 2021 23:39] Report message to a moderator
|
|
|
Re: UppHub - new package registration [message #56148 is a reply to message #56146] |
Mon, 01 February 2021 00:56 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Oblivion wrote on Sun, 31 January 2021 23:37By the way,
Do we really want to use seemingly arbitrary categories in the list? I am almost sure that those tags will be bloom after the takeoff, and we'll probably get redundant category tags like "GUI", "user-interface", etc.
Wouldn't it be better to aling the categories with upp's main directory structure, ie.a functional categorization, like "Core", "Core/Plugin", "CtrlLib", "Draw", "Examples" (users may want to provide more example code with documentation), "Application", etc.
Package readme, if provided, and short summary that appears on the list, already give the idea as to what the package does.
Best regards,
Oblivion
That is why we have list maintainers, right?
|
|
|
|
Re: UppHub - new package registration [message #56156 is a reply to message #56154] |
Mon, 01 February 2021 22:24 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
IMHO, it makes sense to add sections "supported"/"unsupported" to the JSON package registration format because, for example, gdal cannot be compiled with cpp17, Turtle cannot be compiled on Mac, e.t.c.
At least, this should help to understand where a project is supposed to work.
And secondly, this information will be machine-readable and potentially can be used by tools like a build automation system.
Just my two cents.
Regards,
Novo
|
|
|
Re: UppHub - new package registration [message #56157 is a reply to message #56156] |
Mon, 01 February 2021 23:10 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Novo wrote on Mon, 01 February 2021 22:24IMHO, it makes sense to add sections "supported"/"unsupported" to the JSON package registration format because, for example, gdal cannot be compiled with cpp17, Turtle cannot be compiled on Mac, e.t.c.
At least, this should help to understand where a project is supposed to work.
And secondly, this information will be machine-readable and potentially can be used by tools like a build automation system.
Just my two cents.
Yes. Good point. So licenses, supported OSes. I am also thinking about linking documentation root....
Mirek
|
|
|
Re: UppHub - new package registration [message #56159 is a reply to message #56157] |
Tue, 02 February 2021 01:16 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Mon, 01 February 2021 17:10
Yes. Good point. So licenses, supported OSes. I am also thinking about linking documentation root....
Mirek
I'd say supported OSes, compilers (a lot of code won't compile with msvc), version of C++ (gdal won't compile for cpp17, and a lot of code require cpp17 these days).
I'd also add "requires"/"depends_on" for external packages and libraries.
Regards,
Novo
|
|
|
Re: UppHub - new package registration [message #56163 is a reply to message #56094] |
Tue, 02 February 2021 15:58 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
We also need a "branch", because default "master" was changed to "main" and external tools often require an explicit branch name.
That includes my build automation system.
I cannot build MessageCtrl because of that.
Regards,
Novo
|
|
|
|
|
|
Re: UppHub - new package registration [message #56253 is a reply to message #56245] |
Sun, 14 February 2021 20:32 |
|
Klugier
Messages: 1082 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
I would like to point UppHub users to "release-1.10.0" tag instead of main/master branch. Can we add "branch" to the UppHub nest declaration? Alternatively, we could add branches as an array that will point to all available branches that user can select. It will be up to the nest maintainer which branches they want to expose:
{
"name": "GoogleTest",
"packages": [
"plugin/gtest",
"plugin/gmock"
],
"branches": [
"release-1.10.0", // The top is default one
"release-1.9.0",
"release-candidate-1.9.0"
"main" // If you want to risk...
]
"description": "The nest contains GoogleTest and GoogleMock libraries, as U++ packages",
"repository": "https://github.com/klugier/UppGoogleTest.git",
"status": "stable",
"category": "testing",
"readme": "https://raw.githubusercontent.com/klugier/UppGoogleTest/main/README.md" // Upstream README.md is fine, right now. In the future we could change it to readmes and create map with bracnh readme...
},
Thanks to that you could make experiments on main branch without worrying users.
Klugier
U++ - one framework to rule them all.
|
|
|
|
Re: UppHub - new package registration [message #56257 is a reply to message #56256] |
Mon, 15 February 2021 00:41 |
|
Klugier
Messages: 1082 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
I checked the doc and I found that tag can be defined. I created PR I would be grateful if you will review it. Here is my change:
"repository": "https://github.com/klugier/UppGoogleTest.git release-1.10.0",
"readme": "https://raw.githubusercontent.com/klugier/UppGoogleTest/release-1.10.0/README.md"
I understand that this is initial version, so the version management is not must. However, we need to add updates possible and let user even download custom commit/branch/version. I do not ses that ones downloaded branch will stay forever without any updates or possibility to change to certain commit. I know that you can remove and then uninstall, but this is not very handy...
Let's assume that I fixed the problem with my module. Then what? In above case with tag the user can not download anything besides the release-1.10.0. I think option like "Install certain commit/branch/tag.." could work in our case. This will remove whole repo and download repo with certain commit. Clear and simple solution.
I would like to also see if I update global tag like "release-1.10.0" to "release-1.11.0" UppHub detects that there is update and user will have the opportunity to reinstall package. This shouldn't be hard to implement... Background task should do the work.
Klugier
U++ - one framework to rule them all.
[Updated on: Mon, 15 February 2021 00:44] Report message to a moderator
|
|
|
|
Re: UppHub - new package registration [message #56259 is a reply to message #56258] |
Mon, 15 February 2021 01:44 |
|
Klugier
Messages: 1082 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
A) I think for most projects master/main is unstable. If it is stable enough and certain features are present then the master became release via tagging. If it requires more polishing then release branch is created and then tagged if everything is fine. Please look at upp trun (the equivalent of master in git). Sometimes you commit DDUMP and it will not compile. We understand it, because it is trunk. For tagged branch the author guarantees you that it was tested enough, so the trivial problems are not there.
Of course, you could protect master better like running CI/CD (builds and automated tests) on each PR. You can no use direct commits in such case, because you can break compilation. However, you still can sneak some nasty bug that should be eliminated before release (feature freeze phase).
My opinion here is clear. If maintainer provide tagged branch, then it means that users receives more polish and stable product. We should allow that and follow in that direction.
B) The differences between release can be read in releases bookmark on GitHub (Example - similar to Upp Status & Roadmap): https://github.com/klugier/UppGoogleTest/releases). So, the user could be aware of the changes. The use of certain commit/branch could be the situation when you fix certain issue for certain user and would like to give him opportunity to test it from UppHub.
I think we should display in the array "commit/branch" that is actually fetched. On right click with menu we could open dialog where user could specific branch/tag/commit etc... And after accepting he should be re-switched.
C) Agreed!
Anyway, we could discuss it via Skype. For me it is good to clear it up before release.
Klugier
U++ - one framework to rule them all.
[Updated on: Mon, 15 February 2021 01:51] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Sep 20 19:51:03 CEST 2024
Total time taken to generate the page: 0.02988 seconds
|
|
|