unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [ELPA] New package: srht
@ 2022-05-16 16:15 Aleksandr Vityazev
  2022-05-17 12:54 ` Alexander Adolf
  2022-05-17 18:42 ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-16 16:15 UTC (permalink / raw)
  To: emacs-devel@gnu.org

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]


Hello,

I'd like to submit srht.el [1] to GNU ELPA. srht provides bindings to
the Sourcehut REST API as well as commands for interacting with it. It
currently supports two services: git.sr.ht — git hosting and paste.sr.ht
— ad-hoc text file hosting.

[1] https://git.sr.ht/~akagi/srht.el

-- 
Best regards,
Aleksandr Vityazev

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 920 bytes --]

From b454f08ba9b7cd0e1b9f896c670f197683c37758 Mon Sep 17 00:00:00 2001
Message-Id: <b454f08ba9b7cd0e1b9f896c670f197683c37758.1652715289.git.avityazev@posteo.org>
From: Aleksandr Vityazev <avityazev@posteo.org>
Date: Mon, 16 May 2022 15:36:21 +0300
Subject: [PATCH] * elpa-packages (srht): New package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 0a72606e4c..294d95e251 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -585,6 +585,10 @@
  ("sql-cassandra"	:url nil)
  ("sql-indent"          :url "https://github.com/alex-hhh/emacs-sql-indent")
  ("sql-smie"            :url nil)
+ ("srht"                :url "https://git.sr.ht/~akagi/srht.el"
+  :ignored-files ("LICENSE")
+  :doc "README.org"
+  :auto-sync t)
  ("ssh-deploy"		:url "https://github.com/cjohansson/emacs-ssh-deploy")
  ("stream"		:url nil)
  ("svg"			:core ("lisp/svg.el"))
-- 
2.36.0


^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-16 16:15 [ELPA] New package: srht Aleksandr Vityazev
@ 2022-05-17 12:54 ` Alexander Adolf
  2022-05-17 14:49   ` Aleksandr Vityazev
  2022-05-17 16:03   ` Tassilo Horn
  2022-05-17 18:42 ` Stefan Monnier
  1 sibling, 2 replies; 19+ messages in thread
From: Alexander Adolf @ 2022-05-17 12:54 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: emacs-devel


[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

Hello Aleksandr,

Just a quick question which sprang to my mind, and without having looked into the details of your package: does it integrate with magit and forge in any way?

Cheers,

  --alex

-- 
www.condition-alpha.com / @c_alpha
Sent from my iPhone; apologies for brevity and autocorrect weirdness. 

> On 16. May 2022, at 20:02, Aleksandr Vityazev <avityazev@posteo.org> wrote:
> 
> 
> Hello,
> 
> I'd like to submit srht.el [1] to GNU ELPA. srht provides bindings to
> the Sourcehut REST API as well as commands for interacting with it. It
> currently supports two services: git.sr.ht — git hosting and paste.sr.ht
> — ad-hoc text file hosting.
> 
> [1] https://git.sr.ht/~akagi/srht.el
> 
> -- 
> Best regards,
> Aleksandr Vityazev

[-- Attachment #1.2: 0001-elpa-packages-srht-New-package.patch --]
[-- Type: application/octet-stream, Size: 948 bytes --]

From b454f08ba9b7cd0e1b9f896c670f197683c37758 Mon Sep 17 00:00:00 2001
Message-Id: <b454f08ba9b7cd0e1b9f896c670f197683c37758.1652715289.git.avityazev@posteo.org>
From: Aleksandr Vityazev <avityazev@posteo.org>
Date: Mon, 16 May 2022 15:36:21 +0300
Subject: [PATCH] * elpa-packages (srht): New package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 0a72606e4c..294d95e251 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -585,6 +585,10 @@
  ("sql-cassandra"	:url nil)
  ("sql-indent"          :url "https://github.com/alex-hhh/emacs-sql-indent")
  ("sql-smie"            :url nil)
+ ("srht"                :url "https://git.sr.ht/~akagi/srht.el"
+  :ignored-files ("LICENSE")
+  :doc "README.org"
+  :auto-sync t)
  ("ssh-deploy"		:url "https://github.com/cjohansson/emacs-ssh-deploy")
  ("stream"		:url nil)
  ("svg"			:core ("lisp/svg.el"))
-- 
2.36.0


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1944 bytes --]

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 12:54 ` Alexander Adolf
@ 2022-05-17 14:49   ` Aleksandr Vityazev
  2022-05-18 11:15     ` Alexander Adolf
  2022-05-18 12:49     ` Stefan Monnier
  2022-05-17 16:03   ` Tassilo Horn
  1 sibling, 2 replies; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-17 14:49 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: emacs-devel

On 2022-05-17, 14:54 +0200, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:

> Hello Aleksandr,
>
> Just a quick question which sprang to my mind, and without having looked into
> the details of your package: does it integrate with magit and forge in any way?
>
> Cheers,
>
>   --alex
Hello Aleksandr,

No, it's not. According to the documentation, forge already supports the
sourcehut git service. Also forge and magit are not included to ELPA
packages. If I do some integration with other packages, probably it should be
built-in vc. So far, I have no idea how it should look like. The first priority
is to provide support for all sourcehut services.

-- 
Best regards,
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 12:54 ` Alexander Adolf
  2022-05-17 14:49   ` Aleksandr Vityazev
@ 2022-05-17 16:03   ` Tassilo Horn
  1 sibling, 0 replies; 19+ messages in thread
From: Tassilo Horn @ 2022-05-17 16:03 UTC (permalink / raw)
  To: Alexander Adolf; +Cc: Aleksandr Vityazev, emacs-devel

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> Just a quick question which sprang to my mind, and without having
> looked into the details of your package: does it integrate with magit
> and forge in any way?

I've had a brief look and the answer is no.  But I think once more sr.ht
APIs are supported by the package, it might be possible to make forge
work with sr.ht.  But even then, that won't be easy.

I think the basic problem is that with forges like GitHub/GitLab/etc,
once you know the project URL, everything else (issues, PRs, whatever)
can be derived from that.

With sr.ht, that's not the case.  There are many standalone git repos
there which have no project.  Similarly, there are trackers with no
repo.  Or projects with three repos but two trackers.  And there are no
PRs at all but patches are sent to mailinglists of which there can also
be many for one project or one for many projects.

I think the "hub" api will eventually be able to answer questions such
as "what is the issue tracker for project X" or "what is the git/hg repo
for project X" but that's not yet there.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-16 16:15 [ELPA] New package: srht Aleksandr Vityazev
  2022-05-17 12:54 ` Alexander Adolf
@ 2022-05-17 18:42 ` Stefan Monnier
  2022-05-17 19:07   ` Aleksandr Vityazev
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-17 18:42 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: emacs-devel@gnu.org

Aleksandr Vityazev [2022-05-16 16:15:18] wrote:
> I'd like to submit srht.el [1] to GNU ELPA. srht provides bindings to
> the Sourcehut REST API as well as commands for interacting with it. It
> currently supports two services: git.sr.ht — git hosting and paste.sr.ht
> — ad-hoc text file hosting.

Pushed, thanks.
I noticed a significant shortcoming that would be good to fix sooner
rather than later: it seems to presume there's only one SourceHut
instance you interact with.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 18:42 ` Stefan Monnier
@ 2022-05-17 19:07   ` Aleksandr Vityazev
  2022-05-17 19:17     ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-17 19:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel@gnu.org

On 2022-05-17, 14:42 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Aleksandr Vityazev [2022-05-16 16:15:18] wrote:
>> I'd like to submit srht.el [1] to GNU ELPA. srht provides bindings to
>> the Sourcehut REST API as well as commands for interacting with it. It
>> currently supports two services: git.sr.ht — git hosting and paste.sr.ht
>> — ad-hoc text file hosting.
>
> Pushed, thanks.
> I noticed a significant shortcoming that would be good to fix sooner
> rather than later: it seems to presume there's only one SourceHut
> instance you interact with.
>
>
>         Stefan
>


No, in version 0.1 it is already possible to interact with any Sourcehut
instance. Can be specified via the srht-domain variable. Yes, this is perhaps
not entirely clear, I often refer to the sr.ht instance. I think the
documentation should be improved.  Thanks.

-- 
Best regards, 
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 19:07   ` Aleksandr Vityazev
@ 2022-05-17 19:17     ` Stefan Monnier
  2022-05-18 17:47       ` Aleksandr Vityazev
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-17 19:17 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: emacs-devel@gnu.org

> No, in version 0.1 it is already possible to interact with any
> Sourcehut instance.  Can be specified via the srht-domain variable.

That's one variable, hence only one instance.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 14:49   ` Aleksandr Vityazev
@ 2022-05-18 11:15     ` Alexander Adolf
  2022-05-18 12:49     ` Stefan Monnier
  1 sibling, 0 replies; 19+ messages in thread
From: Alexander Adolf @ 2022-05-18 11:15 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: emacs-devel

Aleksandr Vityazev <avityazev@posteo.org> writes:

> [...]
> Also forge and magit are not included to ELPA packages.
> [...]

Good point about the incompatible licence, which I hadn't noticed.


Cheers,

  --alexander



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 14:49   ` Aleksandr Vityazev
  2022-05-18 11:15     ` Alexander Adolf
@ 2022-05-18 12:49     ` Stefan Monnier
  2022-05-18 13:13       ` Tassilo Horn
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-18 12:49 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: Alexander Adolf, emacs-devel

> No, it's not. According to the documentation, forge already supports the
> sourcehut git service. Also forge and magit are not included to ELPA
> packages.

FWIW, Magit is included in NonGNU ELPA and GNU ELPA packages are allowed
to depend on NonGNU ELPA packages (it's not encouraged, admittedly).

I don't know anything about Forge so I don't know if it could be added
to NonGNU ELPA.

Besides, if "integrating with Magit or Forge" doesn't mean depending on
them, but just hooking into (or using) them if/when available, then it
can be done regardless whether they're in (Non)GNU ELPA or not.



        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-18 12:49     ` Stefan Monnier
@ 2022-05-18 13:13       ` Tassilo Horn
  0 siblings, 0 replies; 19+ messages in thread
From: Tassilo Horn @ 2022-05-18 13:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Aleksandr Vityazev, Alexander Adolf, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't know anything about Forge so I don't know if it could be added
> to NonGNU ELPA.
>
> Besides, if "integrating with Magit or Forge" doesn't mean depending
> on them, but just hooking into (or using) them if/when available, then
> it can be done regardless whether they're in (Non)GNU ELPA or not.

I guess it would be the other way round: Forge (or a forge-srht addon
package) could use srht in order to support stuff like creation
of/commenting on tickets, retrieving PRs (which actually means "patches
on a mailinglist" on sr.ht), etc.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-17 19:17     ` Stefan Monnier
@ 2022-05-18 17:47       ` Aleksandr Vityazev
  2022-05-19  4:56         ` Tassilo Horn
  0 siblings, 1 reply; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-18 17:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel@gnu.org

On 2022-05-17, 15:17 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> No, in version 0.1 it is already possible to interact with any
>> Sourcehut instance.  Can be specified via the srht-domain variable.
>
> That's one variable, hence only one instance.
>

Good point, now I understand, will be included in version 0.2.

-- 
Best regards,
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-18 17:47       ` Aleksandr Vityazev
@ 2022-05-19  4:56         ` Tassilo Horn
  2022-05-19 19:10           ` Aleksandr Vityazev
  0 siblings, 1 reply; 19+ messages in thread
From: Tassilo Horn @ 2022-05-19  4:56 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: Stefan Monnier, emacs-devel

Aleksandr Vityazev <avityazev@posteo.org> writes:

>>> No, in version 0.1 it is already possible to interact with any
>>> Sourcehut instance.  Can be specified via the srht-domain variable.
>>
>> That's one variable, hence only one instance.
>
> Good point, now I understand, will be included in version 0.2.

Out of curiosity, what are you planning to do?

I didn't quite get Stefan's compaint to begin with.  I would imagine one
sets srht-domain on a per-project basis, i.e., in a .dir-locals.el file.
Should the package cater for the possibility that a project's git is on
instance 1 but the tracker on instance 2?  Or should there just be a way
to define all instances I want to interact with and then have an
convenient switch-command?  Or should the instance be a mandatory
argument to all functions (which would also be ok if it's just a library
providing access to the srht API) and packages using srht should handle
the "which instance" aspect?

Bye,
Tassilo, who's just trying to make sure we're all on the same page...



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-19  4:56         ` Tassilo Horn
@ 2022-05-19 19:10           ` Aleksandr Vityazev
  2022-05-19 19:50             ` Tassilo Horn
  0 siblings, 1 reply; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-19 19:10 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Stefan Monnier, emacs-devel

On 2022-05-19, 06:56 +0200, Tassilo Horn <tsdh@gnu.org> wrote:

> Aleksandr Vityazev <avityazev@posteo.org> writes:
>
>>>> No, in version 0.1 it is already possible to interact with any
>>>> Sourcehut instance.  Can be specified via the srht-domain variable.
>>>
>>> That's one variable, hence only one instance.
>>
>> Good point, now I understand, will be included in version 0.2.
>
> Out of curiosity, what are you planning to do?
>
> I didn't quite get Stefan's compaint to begin with.  I would imagine one
> sets srht-domain on a per-project basis, i.e., in a .dir-locals.el file.
> Should the package cater for the possibility that a project's git is on
> instance 1 but the tracker on instance 2?  Or should there just be a way
> to define all instances I want to interact with and then have an
> convenient switch-command?  Or should the instance be a mandatory
> argument to all functions (which would also be ok if it's just a library
> providing access to the srht API) and packages using srht should handle
> the "which instance" aspect?

Not to say that srht is a library that simply binds the Sourcehut REST
API. There are also several commands to interact with. As a solution, I
chose the latter by adding an extra mandatory argument for the
functions. The available commands use srht-domains (list of instance
domain names), where users can specify all the instances they want to
interact with. When the command is invoked, it offers instance selection
if srht-domains contains more than one. When used in conjunction with
.dir-locals.el there is little change.

-- 
Best regards,
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-19 19:10           ` Aleksandr Vityazev
@ 2022-05-19 19:50             ` Tassilo Horn
  2022-05-19 21:06               ` Aleksandr Vityazev
  0 siblings, 1 reply; 19+ messages in thread
From: Tassilo Horn @ 2022-05-19 19:50 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: Stefan Monnier, emacs-devel

Aleksandr Vityazev <avityazev@posteo.org> writes:

Hi Aleksandr,

>> Out of curiosity, what are you planning to do?
>>
>> I didn't quite get Stefan's compaint to begin with.  I would imagine
>> one sets srht-domain on a per-project basis, i.e., in a
>> .dir-locals.el file.  Should the package cater for the possibility
>> that a project's git is on instance 1 but the tracker on instance 2?
>> Or should there just be a way to define all instances I want to
>> interact with and then have an convenient switch-command?  Or should
>> the instance be a mandatory argument to all functions (which would
>> also be ok if it's just a library providing access to the srht API)
>> and packages using srht should handle the "which instance" aspect?
>
> Not to say that srht is a library that simply binds the Sourcehut REST
> API. There are also several commands to interact with. As a solution, I
> chose the latter by adding an extra mandatory argument for the
> functions. The available commands use srht-domains (list of instance
> domain names), where users can specify all the instances they want to
> interact with. When the command is invoked, it offers instance selection
> if srht-domains contains more than one. When used in conjunction with
> .dir-locals.el there is little change.

Sounds good.

I've just wanted to give it a try.  The docs of srht-username don't say
wether it is with the ~ or without.

I've generated a new OAuth 2.0 token and put a line in my
~/.authinfo.gpg as stated in the README, i.e.:

  machine sr.ht password <my-oauth-token>

However, when I try to use srht-paste-region I always get this error:

--8<---------------cut here---------------start------------->8---
error in process sentinel: Unkown error with status 400: #s(plz-error nil #s(plz-response 2 400 ((server . "nginx") (date . "Thu, 19 May 2022 20:00:32 GMT") (content-type . "application/json") (content-length . "58") (content-security-policy . "default-src 'none'; style-src 'self' 'unsafe-inline'; img-src * data:; script-src 'self' 'unsafe-inline'")) "{\"errors\": [{\"reason\": \"Invalid or expired OAuth token\"}]}") nil)
--8<---------------cut here---------------end--------------->8---

I've tried srht-username with and without tilde, I've tried using

  machine sr.ht login <username> password <my-oauth-token>

but always got the above error...

Oh, I finally made it!  It seems you cannot use an OAuth 2.0 token but
must use a legacy one.  I'm not sure whose fault that is.  I use a sr.ht
OAuth 2.0 token in hut (the command line client for sr.ht) without
issues.  I think that uses the same REST/GraphQL APIs.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-19 19:50             ` Tassilo Horn
@ 2022-05-19 21:06               ` Aleksandr Vityazev
  2022-05-20  6:05                 ` Tassilo Horn
  0 siblings, 1 reply; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-19 21:06 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Stefan Monnier, emacs-devel

On 2022-05-19, 21:50 +0200, Tassilo Horn <tsdh@gnu.org> wrote:

> Aleksandr Vityazev <avityazev@posteo.org> writes:
>
> Hi Aleksandr,
>
>>> Out of curiosity, what are you planning to do?
>>>
>>> I didn't quite get Stefan's compaint to begin with.  I would imagine
>>> one sets srht-domain on a per-project basis, i.e., in a
>>> .dir-locals.el file.  Should the package cater for the possibility
>>> that a project's git is on instance 1 but the tracker on instance 2?
>>> Or should there just be a way to define all instances I want to
>>> interact with and then have an convenient switch-command?  Or should
>>> the instance be a mandatory argument to all functions (which would
>>> also be ok if it's just a library providing access to the srht API)
>>> and packages using srht should handle the "which instance" aspect?
>>
>> Not to say that srht is a library that simply binds the Sourcehut REST
>> API. There are also several commands to interact with. As a solution, I
>> chose the latter by adding an extra mandatory argument for the
>> functions. The available commands use srht-domains (list of instance
>> domain names), where users can specify all the instances they want to
>> interact with. When the command is invoked, it offers instance selection
>> if srht-domains contains more than one. When used in conjunction with
>> .dir-locals.el there is little change.
>
> Sounds good.
>
> I've just wanted to give it a try.  The docs of srht-username don't say
> wether it is with the ~ or without.

Will work either way, but yes it's worth clarifying.

> I've generated a new OAuth 2.0 token and put a line in my
> ~/.authinfo.gpg as stated in the README, i.e.:
>
>   machine sr.ht password <my-oauth-token>
>
> However, when I try to use srht-paste-region I always get this error:
>
> --8<---------------cut here---------------start------------->8---
> error in process sentinel: Unkown error with status 400: #s(plz-error nil #s(plz-response 2 400 ((server . "nginx") (date . "Thu, 19 May 2022 20:00:32 GMT") (content-type . "application/json") (content-length . "58") (content-security-policy . "default-src 'none'; style-src 'self' 'unsafe-inline'; img-src * data:; script-src 'self' 'unsafe-inline'")) "{\"errors\": [{\"reason\": \"Invalid or expired OAuth token\"}]}") nil)
> --8<---------------cut here---------------end--------------->8---
>
> I've tried srht-username with and without tilde, I've tried using
>
>   machine sr.ht login <username> password <my-oauth-token>
>
> but always got the above error...
>
> Oh, I finally made it!  It seems you cannot use an OAuth 2.0 token but
> must use a legacy one.  I'm not sure whose fault that is.  I use a sr.ht
> OAuth 2.0 token in hut (the command line client for sr.ht) without
> issues.  I think that uses the same REST/GraphQL APIs.

Sourcehut REST API does not support OAuth2 [1], also worth clarifying.
I don't use hut, but after looking a bit, I can tell that only GraphQl
with API2.0 is used there. There is a GraphQl library for Emacs, but
unfortunately neither elpa nor non-gnu elpa has it. 

Thanks for feedback.

[1] https://sourcehut.org/blog/2020-09-25-api-2-updates/
-- 
Best regards,
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-19 21:06               ` Aleksandr Vityazev
@ 2022-05-20  6:05                 ` Tassilo Horn
  2022-05-20 18:39                   ` Aleksandr Vityazev
  2022-05-20 19:08                   ` Stefan Kangas
  0 siblings, 2 replies; 19+ messages in thread
From: Tassilo Horn @ 2022-05-20  6:05 UTC (permalink / raw)
  To: Aleksandr Vityazev; +Cc: Stefan Monnier, emacs-devel

Aleksandr Vityazev <avityazev@posteo.org> writes:

Hi Aleksandr,

>> Oh, I finally made it!  It seems you cannot use an OAuth 2.0 token
>> but must use a legacy one.  I'm not sure whose fault that is.  I use
>> a sr.ht OAuth 2.0 token in hut (the command line client for sr.ht)
>> without issues.  I think that uses the same REST/GraphQL APIs.
>
> Sourcehut REST API does not support OAuth2 [1], also worth clarifying.
> I don't use hut, but after looking a bit, I can tell that only GraphQl
> with API2.0 is used there. There is a GraphQl library for Emacs, but
> unfortunately neither elpa nor non-gnu elpa has it.

Isn't it a bit unfortunate that this new package starts by using the
REST APIs which are described as legacy already and superseeded by the
GraphQL APIs (which are, confessedly, not yet complete for all
services)?  I think the REST APIs will be functional in the mid-term
future, but...

And is GraphQL really so different to REST?  I've never used the former
but at a cursory glance I have the impression that they are quite
similar just that the former is "GraphQL query in, JSON out" whereas the
latter is "JSON in, JSON out".  Is that wrong?

That's mostly to Stefan: WRT, the graphql library [1]: Wouldn't it make
sense to contact the author to include it in GNU ELPA as soon as
possible given that GraphQL seems to be trending nowadays?  Right now,
there's basically just the single author plus some commits from Jonas
(tarsius, the Magit author) who has already signed the CA (plus some
1-line status badge fix by someone else).

Bye,
Tassilo

[1] https://github.com/vermiculus/graphql.el/



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-20  6:05                 ` Tassilo Horn
@ 2022-05-20 18:39                   ` Aleksandr Vityazev
  2022-05-20 19:08                   ` Stefan Kangas
  1 sibling, 0 replies; 19+ messages in thread
From: Aleksandr Vityazev @ 2022-05-20 18:39 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Stefan Monnier, emacs-devel


Hi Tassilo,

On 2022-05-20, 08:05 +0200, Tassilo Horn <tsdh@gnu.org> wrote:

> Aleksandr Vityazev <avityazev@posteo.org> writes:
>
> Hi Aleksandr,
>
>>> Oh, I finally made it!  It seems you cannot use an OAuth 2.0 token
>>> but must use a legacy one.  I'm not sure whose fault that is.  I use
>>> a sr.ht OAuth 2.0 token in hut (the command line client for sr.ht)
>>> without issues.  I think that uses the same REST/GraphQL APIs.
>>
>> Sourcehut REST API does not support OAuth2 [1], also worth clarifying.
>> I don't use hut, but after looking a bit, I can tell that only GraphQl
>> with API2.0 is used there. There is a GraphQl library for Emacs, but
>> unfortunately neither elpa nor non-gnu elpa has it.
>
> Isn't it a bit unfortunate that this new package starts by using the
> REST APIs which are described as legacy already and superseeded by the
> GraphQL APIs (which are, confessedly, not yet complete for all
> services)?  I think the REST APIs will be functional in the mid-term
> future, but...

Yes, that's right, in the long run choosing GraphQl implementation would
be the right thing to do. However, I'm hardly familiar with GraphQl. I
don't think I'll switch to a redesign right now, I'll finish with the
REST API first and then we'll see.

> And is GraphQL really so different to REST?  I've never used the former
> but at a cursory glance I have the impression that they are quite
> similar just that the former is "GraphQL query in, JSON out" whereas the
> latter is "JSON in, JSON out".  Is that wrong?

Yes, that's true and yes they are different and in my opinion
drastically different, although I haven't had to fully explore it yet, I
could be wrong.


-- 
Best regards,
Aleksandr Vityazev



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-20  6:05                 ` Tassilo Horn
  2022-05-20 18:39                   ` Aleksandr Vityazev
@ 2022-05-20 19:08                   ` Stefan Kangas
  2022-05-21 22:30                     ` Jonas Bernoulli
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Kangas @ 2022-05-20 19:08 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Aleksandr Vityazev, Stefan Monnier, Emacs developers

Tassilo Horn <tsdh@gnu.org> writes:

> That's mostly to Stefan: WRT, the graphql library [1]: Wouldn't it make
> sense to contact the author to include it in GNU ELPA as soon as
> possible given that GraphQL seems to be trending nowadays?  Right now,
> there's basically just the single author plus some commits from Jonas
> (tarsius, the Magit author) who has already signed the CA (plus some
> 1-line status badge fix by someone else).

I have no real opinion here, but I note that this library is A) rather
short and B) hasn't been updated in several years.  Perhaps it is a
great opportunity for Someone (TM) to do some greenfield development
and get this on GNU ELPA or even into core, if GraphQL is very
relevant to support.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ELPA] New package: srht
  2022-05-20 19:08                   ` Stefan Kangas
@ 2022-05-21 22:30                     ` Jonas Bernoulli
  0 siblings, 0 replies; 19+ messages in thread
From: Jonas Bernoulli @ 2022-05-21 22:30 UTC (permalink / raw)
  To: Stefan Kangas, Tassilo Horn
  Cc: Aleksandr Vityazev, Stefan Monnier, Emacs developers

Stefan Kangas <stefan@marxist.se> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> That's mostly to Stefan: WRT, the graphql library [1]: Wouldn't it make
>> sense to contact the author to include it in GNU ELPA as soon as
>> possible given that GraphQL seems to be trending nowadays?  Right now,
>> there's basically just the single author plus some commits from Jonas
>> (tarsius, the Magit author) who has already signed the CA (plus some
>> 1-line status badge fix by someone else).
>
> I have no real opinion here, but I note that this library is A) rather
> short and B) hasn't been updated in several years.  Perhaps it is a
> great opportunity for Someone (TM) to do some greenfield development
> and get this on GNU ELPA or even into core, if GraphQL is very
> relevant to support.

Instead of starting from scratch again, I would recommend looking at
existing solutions.

My gsexp.el implements the same functionality as graphql.el: turning
a s-expression into a GraphQL query.  On top of that ghub-graphql.el
implements automatic unpagination.

One huge difference between GraphQL and REST is that the response can
be paginated in several places.  The client has to determine where the
result is incomplete and then it has to send *different* queries to get
that data too.  This is what ghub-graphql-vacuum implements; it fetches
all the requested data without the client having to concern itself with
the details and as if the server did so voluntarily when asked to do so.
Most importantly ghub-graphql derives follow up queries from the initial
query, a task which is rather more complicated than just tacking on
"&page=n+1".

Unfortunately both of these libraries suffer from being severely
under-documented.  gsexp.el also omit at least one features, that I had
no use for: "fragments".  I found those to be very limited; certainly
too limited to be of any use when implementing automatic unpagination.
ghub-graphql.el is maybe a bit too complicated.

gsexp.el and ghub-graphql.el are both maintained in the Ghub
repository (https://github.com/magit/ghub) and are used by
Forge (https://github.com/magit/forge).

IMO what would be most useful at this point would be a test suit, that
could be used to detect gaps in graphql.el/gsexp.el/nih.el, and which
would also demonstrate how to use these libraries and how they differ.

     Jonas



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-05-21 22:30 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-16 16:15 [ELPA] New package: srht Aleksandr Vityazev
2022-05-17 12:54 ` Alexander Adolf
2022-05-17 14:49   ` Aleksandr Vityazev
2022-05-18 11:15     ` Alexander Adolf
2022-05-18 12:49     ` Stefan Monnier
2022-05-18 13:13       ` Tassilo Horn
2022-05-17 16:03   ` Tassilo Horn
2022-05-17 18:42 ` Stefan Monnier
2022-05-17 19:07   ` Aleksandr Vityazev
2022-05-17 19:17     ` Stefan Monnier
2022-05-18 17:47       ` Aleksandr Vityazev
2022-05-19  4:56         ` Tassilo Horn
2022-05-19 19:10           ` Aleksandr Vityazev
2022-05-19 19:50             ` Tassilo Horn
2022-05-19 21:06               ` Aleksandr Vityazev
2022-05-20  6:05                 ` Tassilo Horn
2022-05-20 18:39                   ` Aleksandr Vityazev
2022-05-20 19:08                   ` Stefan Kangas
2022-05-21 22:30                     ` Jonas Bernoulli

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).