IDEA Add-on Updater: Updating your own extensions outside the catalog,


alexey <aleks-samos@...>
 

Hi. How can I force updates to add-ons that are not in the catalog?
I think it's an unnecessary task to write such a module for each of my
add - ons.
For example, update from my site or from Github?
This can be done like this:
In the manifest is specified:
update_url=https://mysite.example.org/update.json
File update.json contains:
{
"version":"2020.11.12",
"download_url": "https://mysite.example.org/myfile-v2020.11.12.nvda-addon"
}
Please consider this possibility in the future.


 

Hi,
Believe it or not I once thought about this idea in the past. Part of the
reason for the current state of Add-on Updater is that it relies on the
infrastructure provided by the community add-ons website. I hope we can
change that in the future once the supposed Add-on Store idea becomes a real
thing (but first, we need to find ways to make the add-on submission process
easier for everyone).
Cheers,
JOseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of alexey
Sent: Wednesday, February 3, 2021 5:48 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] IDEA Add-on Updater: Updating your own extensions
outside the catalog,

Hi. How can I force updates to add-ons that are not in the catalog?
I think it's an unnecessary task to write such a module for each of my add -
ons.
For example, update from my site or from Github?
This can be done like this:
In the manifest is specified:
update_url=https://mysite.example.org/update.json
File update.json contains:
{
"version":"2020.11.12",
"download_url": "https://mysite.example.org/myfile-v2020.11.12.nvda-addon"
}
Please consider this possibility in the future.


alexey <aleks-samos@...>
 

I think we should have
asked the community at the beginning to come up with a unique JSON for the update. Do if the "update_url" is not specified in the manifest, use some default "https://addons.nvda-project.org/files/update.php?file=mySuperScript",
did you ever think about this when you parsed the HTML code of the site and the version numbers in the file name?
And if "update_url" is specified in the manifest, then it is already checked, and since the JSON structure would be the same for everyone, the next steps would be identical,
regardless of whether JSON is downloaded from the community site or from any other third-party site.
I imagined it in my head and I think it's the perfect option!


Reef Turner
 

Hi Alexey,

The proposal for the NVDA addon store submissions is intentionally aiming to keep all metadata in a centralised location. This allows us and the add-ons community to moderate it. The plan involves making the list of add-ons available directly from NVDA, so NV Access must be cautious about what will be available via that list.

For add-on authors who either dislike using or are unfamiliar with GitHub I can recommend the Github CLI tool, which allows creating Pull requests from the command line. I believe this will streamline the process for many users.

I think we are basically at a stage where we can start accepting the json metadata for add-ons to the store. And start offering it from NVDA. One thing I'd like first is a published checklist for reviewing updates to the json data.

To start with we can perform the checks manually, then I hope that some of the people in our community who are experienced with Github Actions can help to automate the checks. If all the checks are automated we will be able to have a very rapid update process.

I should also point out, I expect that the add-ons website is updated to use the same data source. However I believe that this will remain blocked until we have a system in place for translating the metadata.

I hope this helps to explain the approach we are taking. 

Reef Turner
Software Developer - NV Access


On Thu, 4 Feb 2021 at 11:34, alexey <aleks-samos@...> wrote:
I think we should have
asked the community at the beginning to come up with a unique JSON for the update. Do if the "update_url" is not specified in the manifest, use some default "https://addons.nvda-project.org/files/update.php?file=mySuperScript",
did you ever think about this when you parsed the HTML code of the site and the version numbers in the file name?
And if "update_url" is specified in the manifest, then it is already checked, and since the JSON structure would be the same for everyone, the next steps would be identical,
regardless of whether JSON is downloaded from the community site or from any other third-party site.
I imagined it in my head and I think it's the perfect option!






 

Well this is something we need to concidder.

I was thinking about taking an allready existing idea and adapt it to our needs.

Linux allready has repos of packages,

And an easy way to add extra repos.

The issue really should be who has access to addons infrastructure.

Something changed a bit ago which stopped part of this working.

Yes there are a few mirrors some with alegal stuff on them but not official.

There are more git repos than there are addons, and to add an addon to updater this needs to be done manually.

At this point it really needs to be that there is a central list where official addon authors have their addons, linux has official and unofficial repositories allready.

So all we need is a good package manager.

The nvda addon updater sounds nice, but maybe we need to take an allready established package manager and use that or at least something from that.

There should be things like the ability from nvda to switch between dev, alpha, beta and stable channels, and the ability to switch from addon channels etc easily enough.

As I said on the other thread, we really need to sort out the infrastructure or a way to get addons if for example it should fail.

At any rate, all we need is a mirror for official and one for unofficial.

Now we just need something to check releases and devs say once a day, maybe overnight, but have a way for a user to post directly and update their rrepo and also notify the updater manually, obviously they will need access to do that, but git access should be  good enough even if you then have google access on top of that and whatever security.

Then again, you could just say that every developer needs pgp or other key access both private or public for verification.

Thats a bit of an effort but what's 1 or 2 more packages when a usual source project usually has 30 or more packages.

I just ran updates on some source projects I am testing, I had to update several packages and I need to do some modifying of several files to have updated packages.

On 4/02/2021 3:53 pm, Joseph Lee wrote:
Hi,
Believe it or not I once thought about this idea in the past. Part of the
reason for the current state of Add-on Updater is that it relies on the
infrastructure provided by the community add-ons website. I hope we can
change that in the future once the supposed Add-on Store idea becomes a real
thing (but first, we need to find ways to make the add-on submission process
easier for everyone).
Cheers,
JOseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of alexey
Sent: Wednesday, February 3, 2021 5:48 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] IDEA Add-on Updater: Updating your own extensions
outside the catalog,

Hi. How can I force updates to add-ons that are not in the catalog?
I think it's an unnecessary task to write such a module for each of my add -
ons.
For example, update from my site or from Github?
This can be done like this:
In the manifest is specified:
update_url=https://mysite.example.org/update.json
File update.json contains:
{
"version":"2020.11.12",
"download_url": "https://mysite.example.org/myfile-v2020.11.12.nvda-addon"
}
Please consider this possibility in the future.









.


 

What about when you install addons, really should have a list of addons, and you can open one to hear its description then add to and get that.

You could always download addons  and such.

I'd also like the ability to have an account, add into what I need say addons I use a lot, then download a huge file for backup then only 1 file would install it all.

I wander if we could use ninite to install extras like addons since it will always get latest releases.

On 4/02/2021 4:34 pm, alexey wrote:
I think we should have
asked the community at the beginning to come up with a unique JSON for the update. Do if the "update_url" is not specified in the manifest, use some default "https://addons.nvda-project.org/files/update.php?file=mySuperScript",
did you ever think about this when you parsed the HTML code of the site and the version numbers in the file name?
And if "update_url" is specified in the manifest, then it is already checked, and since the JSON structure would be the same for everyone, the next steps would be identical,
regardless of whether JSON is downloaded from the community site or from any other third-party site.
I imagined it in my head and I think it's the perfect option!




.


 

Well I use github cli for some stuff in elektron forge but I also have github desktop which I use all the time.

Its easy to clone repos and stuff though I need to get their git links off the site first.

As for a centralised place, I do wander why all the centralised information couldn't be stored in ini files or text files.

Not sure how to do xml stuff but that is a commen way of storing all sorts of data.



On 4/02/2021 5:30 pm, Reef Turner wrote:
Hi Alexey,

The proposal for the NVDA addon store submissions is intentionally aiming to keep all metadata in a centralised location. This allows us and the add-ons community to moderate it. The plan involves making the list of add-ons available directly from NVDA, so NV Access must be cautious about what will be available via that list.

For add-on authors who either dislike using or are unfamiliar with GitHub I can recommend the Github CLI tool, which allows creating Pull requests from the command line. I believe this will streamline the process for many users.

I think we are basically at a stage where we can start accepting the json metadata for add-ons to the store. And start offering it from NVDA. One thing I'd like first is a published checklist for reviewing updates to the json data.

To start with we can perform the checks manually, then I hope that some of the people in our community who are experienced with Github Actions can help to automate the checks. If all the checks are automated we will be able to have a very rapid update process.

I should also point out, I expect that the add-ons website is updated to use the same data source. However I believe that this will remain blocked until we have a system in place for translating the metadata.

I hope this helps to explain the approach we are taking. 

Reef Turner
Software Developer - NV Access


On Thu, 4 Feb 2021 at 11:34, alexey <aleks-samos@...> wrote:
I think we should have
asked the community at the beginning to come up with a unique JSON for the update. Do if the "update_url" is not specified in the manifest, use some default "https://addons.nvda-project.org/files/update.php?file=mySuperScript",
did you ever think about this when you parsed the HTML code of the site and the version numbers in the file name?
And if "update_url" is specified in the manifest, then it is already checked, and since the JSON structure would be the same for everyone, the next steps would be identical,
regardless of whether JSON is downloaded from the community site or from any other third-party site.
I imagined it in my head and I think it's the perfect option!






Noelia Ruiz
 

Hi Reef, thanks for mentioning GitHub cli. I had not tested it and
this is amazing, and we can even run gh pr checks to see if GitHub
Actions have been successful.
I¡ve created a pull request since yesterday a new issue was created
for cursorLocator add-on, and I've used GitHub cli.
I may publish a post on the website created by me for spanish NVDA's
community, at nvdaes.github.io, mentioning this thread and your
suggestion.
About GitHub Actions to perform some checks, I find them very useful.
Anyway, I think that some type edit field for user comments should be
provided too.
Kind regards.

2021-02-04 5:30 GMT+01:00, Reef Turner <reef@nvaccess.org>:

Hi Alexey,

The proposal for the NVDA addon store submissions is intentionally aiming
to keep all metadata in a centralised location. This allows us and the
add-ons community to moderate it. The plan involves making the list of
add-ons available directly from NVDA, so NV Access must be cautious about
what will be available via that list.

For add-on authors who either dislike using or are unfamiliar with GitHub I
can recommend the Github CLI tool, which allows creating Pull requests from
the command line. I believe this will streamline the process for many
users.

I think we are basically at a stage where we can start accepting the json
metadata for add-ons to the store. And start offering it from NVDA. One
thing I'd like first is a published checklist for reviewing updates to the
json data.

To start with we can perform the checks manually, then I hope that some of
the people in our community who are experienced with Github Actions can
help to automate the checks. If all the checks are automated we will be
able to have a very rapid update process.

I should also point out, I expect that the add-ons website is updated to
use the same data source. However I believe that this will remain blocked
until we have a system in place for translating the metadata.

I hope this helps to explain the approach we are taking.

Reef Turner
Software Developer - NV Access


On Thu, 4 Feb 2021 at 11:34, alexey <aleks-samos@yandex.ru> wrote:

I think we should have
asked the community at the beginning to come up with a unique JSON for
the
update. Do if the "update_url" is not specified in the manifest, use some
default "
https://addons.nvda-project.org/files/update.php?file=mySuperScript",
did you ever think about this when you parsed the HTML code of the site
and the version numbers in the file name?
And if "update_url" is specified in the manifest, then it is already
checked, and since the JSON structure would be the same for everyone, the
next steps would be identical,
regardless of whether JSON is downloaded from the community site or from
any other third-party site.
I imagined it in my head and I think it's the perfect option!










Brian's Mail list account
 

Also of course the all important security issues need to be looked at in any new version, just in case the author has missed something.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Thursday, February 04, 2021 2:53 AM
Subject: Re: [nvda-addons] IDEA Add-on Updater: Updating your own extensions outside the catalog,


Hi,
Believe it or not I once thought about this idea in the past. Part of the
reason for the current state of Add-on Updater is that it relies on the
infrastructure provided by the community add-ons website. I hope we can
change that in the future once the supposed Add-on Store idea becomes a real
thing (but first, we need to find ways to make the add-on submission process
easier for everyone).
Cheers,
JOseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of alexey
Sent: Wednesday, February 3, 2021 5:48 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] IDEA Add-on Updater: Updating your own extensions
outside the catalog,

Hi. How can I force updates to add-ons that are not in the catalog?
I think it's an unnecessary task to write such a module for each of my add -
ons.
For example, update from my site or from Github?
This can be done like this:
In the manifest is specified:
update_url=https://mysite.example.org/update.json
File update.json contains:
{
"version":"2020.11.12",
"download_url": "https://mysite.example.org/myfile-v2020.11.12.nvda-addon"
}
Please consider this possibility in the future.