| Message ID | 20220815114227.10424-1-raingloom@riseup.net |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#57118,v2] gnu: Add linode-cli. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Hi, raingloom <raingloom@riseup.net> skribis: > From: Csepp <raingloom@riseup.net> > > * gnu/packages/python-xyz.scm (linode-cli) (linode-openapi-spec): New variables. [...] > +;; linode-cli would normally fetch this at build time > +;; TODO: is there a way to refer to previous versions? is there even a point > +;; in trying to? > +(define linode-openapi-spec > + (origin > + (method url-fetch) > + (uri "https://www.linode.com/docs/api/openapi.yaml") > + (sha256 > + (base32 > + "1jcjfnagjihcy03fcmn5sghdf7a80798xjgj1x7z3ncqwd5aggwg")))) Unfortunately, as you probably guess, this file was updated in place and the hash is now different. Is there a stable URL for the specific version we’d want to use here? Otherwise it’s just too shaky: the thing will fail to build a week or month later, when linode.com decides to update that file. With this fixed, the patch is ready to go. Thanks in advance, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > raingloom <raingloom@riseup.net> skribis: > >> From: Csepp <raingloom@riseup.net> >> >> * gnu/packages/python-xyz.scm (linode-cli) (linode-openapi-spec): New variables. > > [...] > >> +;; linode-cli would normally fetch this at build time >> +;; TODO: is there a way to refer to previous versions? is there even a point >> +;; in trying to? >> +(define linode-openapi-spec >> + (origin >> + (method url-fetch) >> + (uri "https://www.linode.com/docs/api/openapi.yaml") >> + (sha256 >> + (base32 >> + "1jcjfnagjihcy03fcmn5sghdf7a80798xjgj1x7z3ncqwd5aggwg")))) > > Unfortunately, as you probably guess, this file was updated in place and > the hash is now different. > > Is there a stable URL for the specific version we’d want to use here? > Otherwise it’s just too shaky: the thing will fail to build a week or > month later, when linode.com decides to update that file. > > With this fixed, the patch is ready to go. > > Thanks in advance, > Ludo’. I skimmed the OpenAPI spec and couldn't find any mention of how to access previous versions. IMHO if there is a build failure, guix refresh -u should take care of updating the hash. It's better than trying to use an outdated API description without notifying the user.
Hi, Csepp <raingloom@riseup.net> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >>> +(define linode-openapi-spec >>> + (origin >>> + (method url-fetch) >>> + (uri "https://www.linode.com/docs/api/openapi.yaml") >>> + (sha256 >>> + (base32 >>> + "1jcjfnagjihcy03fcmn5sghdf7a80798xjgj1x7z3ncqwd5aggwg")))) [...] > I skimmed the OpenAPI spec and couldn't find any mention of how to > access previous versions. OK. > IMHO if there is a build failure, guix refresh -u should take care of > updating the hash. It's better than trying to use an outdated API > description without notifying the user. I should say I don’t know what this file is used for. :-) What I do know is that we should avoid having origins like that above that are bound to fail. Perhaps we can find another option? If the CLI tools really need the latest version of ‘openapi.yaml’, could they download it (and possibly cache it) at run time? Perhaps there are already provisions for that? If the tools don’t strictly need the latest version, then hopefully Linode keeps a copy of this file in a Git repo somewhere? TIA, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Csepp <raingloom@riseup.net> skribis: > >> Ludovic Courtès <ludo@gnu.org> writes: > > [...] > >>>> +(define linode-openapi-spec >>>> + (origin >>>> + (method url-fetch) >>>> + (uri "https://www.linode.com/docs/api/openapi.yaml") >>>> + (sha256 >>>> + (base32 >>>> + "1jcjfnagjihcy03fcmn5sghdf7a80798xjgj1x7z3ncqwd5aggwg")))) > > [...] > >> I skimmed the OpenAPI spec and couldn't find any mention of how to >> access previous versions. > > OK. > >> IMHO if there is a build failure, guix refresh -u should take care of >> updating the hash. It's better than trying to use an outdated API >> description without notifying the user. > > I should say I don’t know what this file is used for. :-) > > What I do know is that we should avoid having origins like that above > that are bound to fail. Perhaps we can find another option? If the CLI > tools really need the latest version of ‘openapi.yaml’, could they > download it (and possibly cache it) at run time? Perhaps there are > already provisions for that? > > If the tools don’t strictly need the latest version, then hopefully > Linode keeps a copy of this file in a Git repo somewhere? > > TIA, > Ludo’. Oh wow, the git repo suggestion was head on. I didn't think they would have something like that, but alas, they do: https://github.com/linode/linode-api-docs/blob/development/openapi.yaml It doesn't really have a license though, I'm not sure if that's a problem. Would we get in trouble for redistributing it?
Hi, Csepp <raingloom@riseup.net> skribis: > Oh wow, the git repo suggestion was head on. I didn't think they would > have something like that, but alas, they do: > https://github.com/linode/linode-api-docs/blob/development/openapi.yaml > > It doesn't really have a license though, I'm not sure if that's a problem. > Would we get in trouble for redistributing it? Could you open an issue upstream asking them to clarify that? Thanks, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Csepp <raingloom@riseup.net> skribis: > >> Oh wow, the git repo suggestion was head on. I didn't think they would >> have something like that, but alas, they do: >> https://github.com/linode/linode-api-docs/blob/development/openapi.yaml >> >> It doesn't really have a license though, I'm not sure if that's a problem. >> Would we get in trouble for redistributing it? > > Could you open an issue upstream asking them to clarify that? > > Thanks, > Ludo’. Finally got around to this, let's see how they respond. https://github.com/linode/linode-api-docs/issues/677
On 01-09-2022 22:06, Csepp wrote: > > [...] > Oh wow, the git repo suggestion was head on. I didn't think they would > have something like that, but alas, they do: > https://github.com/linode/linode-api-docs/blob/development/openapi.yaml > > It doesn't really have a license though, I'm not sure if that's a problem. > Would we get in trouble for redistributing it? Sources (not only code (*), also it's documentation) needs to not only be redistributable, but also modifiable. (*) it seems mostly 'data' (+ documentation), but it's data that to a large degree controls how the program works, so seems rather important data to me (e.g. what if you make your own version of 'linode.com' and need to tweak the openapi.yaml to accomodate your own version that behaves differently in some aspects, or removes or adds parts?). Greetings, Maxime.
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm index e5326274c0..f299476f47 100644 --- a/gnu/packages/python-xyz.scm +++ b/gnu/packages/python-xyz.scm @@ -30353,3 +30353,70 @@ (define-public i3-autotiling "Script for Sway and i3 to automatically switch the horizontal/vertical window split orientation.") (license license:gpl3))) + +;; linode-cli would normally fetch this at build time +;; TODO: is there a way to refer to previous versions? is there even a point +;; in trying to? +(define linode-openapi-spec + (origin + (method url-fetch) + (uri "https://www.linode.com/docs/api/openapi.yaml") + (sha256 + (base32 + "1jcjfnagjihcy03fcmn5sghdf7a80798xjgj1x7z3ncqwd5aggwg")))) + +(define-public linode-cli + (package + (name "linode-cli") + (version "5.22.0") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/linode/linode-cli") + (commit version))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "1fv53wikx745kci86xrsq9kfsgv0a65srhywdw32cab1wywwpn2z")))) + (build-system python-build-system) + (arguments (list + #:tests? #f ;; requires personal access token + #:phases + #~(modify-phases %standard-phases + (add-after 'build 'bake-api + (lambda _ + ;; The "build" make target tries to do some Python 2 + ;; stuff, so instead we just take the two lines we care + ;; about: + (invoke "python3" "-m" "linodecli" "bake" + #+linode-openapi-spec + "--skip-config") + (copy-file "data-3" "linodecli/data-3"))) + (add-before 'install 'fix-bash-completions-path + (lambda _ + ;; rename it so setup.py thinks it's missing and + ;; doesn't try to install it to /etc + (rename-file "linode-cli.sh" "completions") + ;; TODO for some reason these don't work? + ;; I don't use bash, so I leave it for someone else to + ;; figure out. + (install-file + "completions" + (string-append #$output "/share/bash-completion/")))) + (replace 'sanity-check + (lambda _ + ;; this way it doesn't ask for an access token + (invoke "linode-cli" "--version" "--skip-config")))))) + (inputs + (list + python-terminaltables + python-requests + python-pyyaml)) + (synopsis "Tool for managing Linode resources") + (home-page "https://www.linode.com/docs/products/tools/cli/") + (description + "A wrapper around the Linode API, which gives you the ability to manage +your Linode account from the command line. Almost any task that can be done +through the Cloud Manager can also be performed through the CLI.") + (license license:bsd-3)))
From: Csepp <raingloom@riseup.net> * gnu/packages/python-xyz.scm (linode-cli) (linode-openapi-spec): New variables. --- gnu/packages/python-xyz.scm | 67 +++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+)