Update/Change `KIGITHUB` variable

Description

• The KIGITHUB variable is obsolete and should be removed

Steps to reproduce

• Install kicad
• Remove ~/.config/kicadnightly/5.99 folder to start with an empty profile
• Start kicad, the variable gets created

KiCad Version

Application: KiCad

Version: 5.99.0-unknown-dbcb1ecdb~104~ubuntu20.10.1, release build

Libraries:
	wxWidgets 3.0.5
	libcurl/7.72.0 OpenSSL/1.1.1g zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.41.0 librtmp/2.3

Platform: Linux 5.8.0-2-amd64 x86_64, 64 bit, Little endian, wxGTK, i3, x11

Build Info:
	Date: Oct 25 2020 10:19:24
	wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
	Boost: 1.71.0
	OCE: 6.9.1
	Curl: 7.68.0
	ngspice: 32
	Compiler: GCC 10.2.0 with C++ ABI 1014

Build settings:
	KICAD_SCRIPTING=ON
	KICAD_SCRIPTING_MODULES=ON
	KICAD_SCRIPTING_PYTHON3=ON
	KICAD_SCRIPTING_WXPYTHON=ON
	KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
	KICAD_SCRIPTING_ACTION_MENU=ON
	BUILD_GITHUB_PLUGIN=ON
	KICAD_USE_OCE=ON
	KICAD_SPICE=ON

added priorityundecided statusnew labels

I think solution is under:

line 262 KIGITHUB

line 275 https://github.com/KiCad

of common/pgm_base.cpp file. But not sure.

Should this be removed or changed to KIGITLAB https://gitlab.com/kicad accordingly?

Removed. It was a v4 thing to download libs from github. AFAIK there is no use for that variable anymore.

The GitHub plugin is still enabled in default KiCad builds so this environment variable cannot go away.

closed

Well, there is the problem that we no longer host the libraries on GitHub though, so this will be pointing to outdated libraries. We need to do something with this for v6 to update it at least.

reopened

changed title from Remove KIGITHUB variable to Update/Change KIGITHUB variable

This would be up to users to change the URL to point to their GitHub repos so I don't see how we can know what to set it to.

Wouldn't it also be up to them to set the environmental variable?

The plugin uses GitHub specific download formatting, so we can't move it to GitLab. Users would need to input their own GitHub repositories if they want to use their libraries on GitHub

For v7, does it make sense to add support for (remote) git libraries? E.g. using libgit2 to automatically sync the repo into some user directory. This should be a suitable replacement for the Github plugin, and is even offline capable.

Directly handling git even with libgit2 is going to crawl so far up the "workflow" domain that someone will be constantly fixing complaints. "I want it to pull --rebase each time!" "I want it to shallow pull" "I want it to merge!" "I want it to give me a diff and let me cherry pick!"

Heh.

For v7, does it make sense to add support for (remote) git libraries? E.g. using libgit2 to automatically sync the repo into some user directory. This should be a suitable replacement for the Github plugin, and is even offline capable.

I am hesitant to go down this road, and in the past we have said we really don't want to integrate version control systems into our code (why should we reimplement a git client when there are plenty of them?)

The plugin uses GitHub specific download formatting, so we can't move it to GitLab. Users would need to input their own GitHub repositories if they want to use their libraries on GitHub

Then I definitely am questioning why we are going to provide links to the official KiCad libraries that are no longer being updated as the default for the plugin. I think this is better left to the docs, so they explain how to use the plugin, and as part of that what the proper environment variable to set is to use it. If we do that, I think we should remove the variable (or at least change it to something like please change me so it is obvious).

I'm in favor of removing the GitHub plugin altogether. It hasn't been updated this entire release cycle and only minimally touched during v5 only to fix a caching bug and make it harder to find. We're not really supporting it. I don't see the value in maintaining a feature that was never fully implemented, has caused considerable problems and no one is invested in updating. The major version release is the correct time to remove this.

You might want to do a quick poll on the user forum and the developer mailing list just to make sure no one is actually still using it before removing it. Otherwise, be prepared for the blow back if they are.

Done. I'll give it a few days to see who bites.

Owner of V4 repositories might want to check Insights/Traffic page on GitHub to estimate if the repositories are used. I don't know if access from KiCad shows there though.

The deafening silence on both fronts suggests that reaction will likely be muted.

If you want a response, the best thing to do is just remove it. Only then will people complain ;)

For v7, does it make sense to add support for (remote) git libraries? E.g. using libgit2 to automatically sync the repo into some user directory. This should be a suitable replacement for the Github plugin, and is even offline capable.

Of course it does !!!! We are in 2020, 10 years after this 'thing' was written. At the time, there was not a real lib as of today. You probably had to roam the internet to find the symbol somewhere. All that 'shit' is from the past.'fplibtables' has to be blown. That was used to limit memory probably, deal with lots of sources too.

Now 90% of symbols footprints are available and when you create some, you just expect to save them in your project's implicit auto created directory !

And when the librarian team will be functional, a personaly created footprint will be submitted, revised, published and globaly distributed in less than 30 days (dream).

And when the librarian team will be functional

The library team is proud of being purely imperative!

@Franck78 You have been warned multiple times about posting abusive comments to the KiCad issue tracker. We have an established code of conduct that all members of the KiCad team abide by. As a bug reporter, you are also expected to follow these minimal requirements for professional behavior.

Because you have not followed these requirements, you currently have a 30 day suspension from posting to the KiCad issue tracker. Any comments or issues that you post during this time will be deleted.

After 30 days, we will lift the suspension. If you continue to post abusive, vulgar or derogatory comments, we will permanently ban you from the KiCad issue tracker.

Flagging as 6.0rc just so we don't lose track of it.

If we decide to wait based on feedback from the user forum we can remove the milestone....

changed milestone to %6.0.0-rc1

closed with commit 9ed6cdd9

added statusfix-committed label and removed statusnew label

Hi, I came late :'( I missed the forum's mail 2 weeks ago.

Actually the name is missleading, the GitHub plugin is simply a remote retrieving plugin.

Did you know that using the GitHub plugin you can also retrieve footprints from GitLab (or any other zipped link). For example we retrieve without external action (ie. git clone sudo cp thing before running) the following link : https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/master/kicad-footprints-master.zip?path=Module.pretty

Perhaps instead of removing it, we needed to simply update the name?

It isn't a fix, but rather a functional regression :'( :'(

It is more than a 'get zipfile plugin'. See here 9ed6cdd9 (Line 510) There is a code-path for github, and one for just zip files.

Quite a lot of stuff is hard-coded for github, check the diff of 9ed6cdd9 for more locations.

But you are right, this is also a zipfile-plugin. A workaround for your usecase is to use a few lines of bash to archive the same thing. Download the file and extract it. Or is there something else?

It is more than a 'get zipfile plugin'. See here 9ed6cdd9 (Line 510) There is a code-path for github, and one for just zip files.

Quite a lot of stuff is hard-coded for github, check the diff of 9ed6cdd9 for more locations.

Yes I know them well, am currently cleaning all that stuff in my branch (+renaming it) to keep the plugin remote/zip only.

A workaround for your usecase is to use a few lines of bash to archive the same thing. Download the file and extract it.

Yes, that's the default way (a git pull list all files unzip all script), every body can tweek to meet the need.

Kicad now isn't only for hobby use, many are using it in a professional context.

The thing is that in a company, the paradigm is different from hobby, you kill any wasting/useless operation. Specially when you work very often in a new board.

When you hire someone you can either say the first day: "you need to get the script, and lunch it before every run, and check that the libs are updated....etc" -> 10% the time he calls you "I didn't find the component" then you answer, "did you run the script?" he says yes, then on so on so on... (true story)

Or, rather prefer saying: "run kicad, and all updated"

In our case we automated everything, and even working on a mysql plugin to be able to track the updates at the level of the component.

As I said it was late when I saw the group email. It would be preferable if the KIGITHUB env var was removed as a first step, and clean the function step by step, not remove all at once. I'll try to fix drawbacks to make it more stable for a large panel of user.

mentioned in issue #4612 (closed)

mentioned in merge request kicad/packaging/kicad-ubuntu-builder/kicad-daily-package!1 (merged)