Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocpn-install: Cannot parse plugin name from tarball name #60

Closed
leamas opened this issue Mar 26, 2020 · 4 comments · Fixed by #61
Closed

ocpn-install: Cannot parse plugin name from tarball name #60

leamas opened this issue Mar 26, 2020 · 4 comments · Fixed by #61

Comments

@leamas
Copy link
Contributor

leamas commented Mar 26, 2020

Currently, ocpn-install parses the plugin from tarball name, using a simple heuristic the any plugins called name_pi has a plugin name (common name name.

This heuristic does not hold. The only reliable way to get the filename is from the xml metadata. See discussion in bdbcat/oesenc_pi#79

@rgleason
Copy link
Contributor

rgleason commented Mar 26, 2020

It's good this is happening now, as it will be a little disruptive to creating good catalogs.
It seems to me that the field must match exactly the "CommonName" found by searchiing for "GetCommonName" in the )_pi.cpp file. What is wrong with that?

I assume "tarball name" is the 'tarball-URL'. Quite frankly, I have seen many 'tarball-URL' that do not match the "CommonName" as they are changed, fixed and doctored throughout the Frontend process (both frontends).

I am just saying that by using 'tarball-URL' we will really have to clean it all up so that it matches "CommonName" and that will take some time and effort. I hope we can nail this down.

@rgleason
Copy link
Contributor

rgleason commented Mar 26, 2020

From Tarball Names
plugin name>-<version>[-release]_<target os>-<target os version>.tar.gz
Later: fixed
However in the "Tarball-URL" here is one example:

weatherfax-darwin-10.13.6-macos-tarball/versions/1.9.4.1+178.01c1c13/weatherfax_pi-1.9.4.1-ov50-1.16_darwin-10.13.6-macos.tar.gz

In this case I know that the CommonName is actually "WeatherFax".
Also there are additional designations at the end or the beginning (don't know which).

  • Beginning: " weatherfax-darwin-10.13.6-macos-tarball"
  • Middle: "versions/1.9.4.1+178.01c1c13/" what is it for?
  • End: "weatherfax_pi-1.9.4.1-ov50-1.16_darwin-10.13.6-macos.tar.gz"

Is there any reason this can't be shortened somewhat?
Which part is the part that we should be looking at?
I don't see how either the Beginning or End match the example at the top.

@leamas
Copy link
Contributor Author

leamas commented Mar 27, 2020

From Tarball Names
"plugin name>-[-release]_-.tar.gz"

The actual quote is <plugin name>-<version>[-release]_<target os>-<target os version>.tar.gz

Which means that weatherfax_pi-1.9.4.1-ov50-1.16_darwin-10.13.6-macos.tar.gz will be parsed as
name: weatherfax_pi
version: 1.9.4.1
release: ov50-1.16
target-os: darwin
target-os-version: 10.13.6-macos

Everything here is just fine besides target-os-version which should be 10.13.6 (drop the -macos suffix, it duplicates the darwin part)

EDIT: Note that the common name stuff is dropped, it will not be possible to force plugins to use the common name as the name in the tarball. We are leaving this as it is, using the established name typically with a _pi suffix.

@rgleason
Copy link
Contributor

Thanks.
"it will not be possible to force plugins to use the common name"
Why not? It makes perfect sense to use the "CommonName" for consistency.
Is it the capitals or something? Or just to chicken to change it?

So the Tarball Name is at the "end" and should be:
weatherfax_pi-1.9.4.1-ov50-1.16_darwin-10.13.6.tar.gz

What are the "Beginning" and "Midddle" parts of the Target-URL?

@leamas leamas mentioned this issue Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants