Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » UppHub - new package registration (How do we want to solve this problem?)
icon5.gif  UppHub - new package registration [message #56094] Sat, 23 January 2021 22:13 Go to next message
Klugier is currently offline  Klugier
Messages: 1075
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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Sat, 23 January 2021 22:13
Hello,

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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 #56127 is a reply to message #56118] Sat, 30 January 2021 12:18 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
Hello Mirek,
I think the package licenses (BSD/MIT/GPL, etc.) should also be displayed on the packages list. It is an important info.


Also, I an eager to move at lease some components to UppHub, if not the whole upp-components repo.
I am currenty assesing a viable strategy to do that. (I need to keep upp-componetns repo intact, possibly synced with upphub pckages, as I can't assume that all users use TheIDE or Upp >= 2021.1)


Best regards,
Oblivion.


[Updated on: Sat, 30 January 2021 17:35]

Report message to a moderator

Re: UppHub - new package registration [message #56130 is a reply to message #56127] Sat, 30 January 2021 20:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Have a good strategy for moving packages from bazaar (basically, import upp, clone it, delete everything except the package(s) you want to move, move package to repo root) - I will post the recipe soon in bazaar.

Good point about the licenses.

Mirek
Re: UppHub - new package registration [message #56146 is a reply to message #56130] Sun, 31 January 2021 23:37 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
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


[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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Oblivion wrote on Sun, 31 January 2021 23:37
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


That is why we have list maintainers, right?
Re: UppHub - new package registration [message #56154 is a reply to message #56148] Mon, 01 February 2021 11:26 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
Ok, then.

I have attempted to register my first upphub package (MessageCtrl) and called it a "widget" (for the time being, until we come up with a better categorization scheme) Smile

Best regards,
Oblivion.


[Updated on: Mon, 01 February 2021 11:37]

Report message to a moderator

Re: UppHub - new package registration [message #56156 is a reply to message #56154] Mon, 01 February 2021 22:24 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 February 2021 22:24
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.


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 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 #56169 is a reply to message #56130] Tue, 02 February 2021 22:59 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
Hello Mirek,

I have noticed an issues with the license and readme files: Since these files reside in the root directory, TheIDE is unable to read them (in the license information window or via the package files section.)


Best regards,
Oblivion


Re: UppHub - new package registration [message #56244 is a reply to message #56169] Sat, 13 February 2021 08:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Oblivion wrote on Tue, 02 February 2021 22:59
Hello Mirek,

I have noticed an issues with the license and readme files: Since these files reside in the root directory, TheIDE is unable to read them (in the license information window or via the package files section.)


Best regards,
Oblivion


You can still open them with "Open any file", no? And Copying should be inside the package (maybe as duplicate).
Re: UppHub - new package registration [message #56245 is a reply to message #56244] Sat, 13 February 2021 09:00 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
One general suggestion: Let us tone down a bit "Ultimate". I am trying to use U++ instead everywhere.

E.g. package maintainers should suggest replacing Ultimate++ with U++ in readme files and elsewhere.

Mirek

[Updated on: Sat, 13 February 2021 10:22]

Report message to a moderator

Re: UppHub - new package registration [message #56253 is a reply to message #56245] Sun, 14 February 2021 20:32 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
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 #56256 is a reply to message #56253] Sun, 14 February 2021 23:56 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
The branch to be installed is there since the beginning - check the docs
Re: UppHub - new package registration [message #56257 is a reply to message #56256] Mon, 15 February 2021 00:41 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
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 #56258 is a reply to message #56257] Mon, 15 February 2021 00:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Mon, 15 February 2021 00:41

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...


You can always create normal nest and git clone anything there.

Quote:


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.


a) I think it should be other way around. master is always current stable version. If you want to experiment, experiment in branch.
b) Well, I actually agree there is an utility in this. But I do not yet see how to do it right. Should e.g. there be some global branch names? How will user know what difference is between branches?
c) Also, UppHub does not need branches listed - that information can be loaded from the git.

There is BTW one other much more serious problem and that is a release of user's application. I have solution for that...

Mirek
Re: UppHub - new package registration [message #56259 is a reply to message #56258] Mon, 15 February 2021 01:44 Go to previous messageGo to previous message
Klugier is currently offline  Klugier
Messages: 1075
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

Previous Topic: How can I use CORE/SSL to sign something or check signatures?
Next Topic: How does one get argc and argv parms when making use of GUI_APP_MAIN?
Goto Forum:
  


Current Time: Thu Mar 28 10:44:40 CET 2024

Total time taken to generate the page: 0.01257 seconds