Unable to install magit due to ghub->graphql?

[joecox]

Hi! I recently (in the last hour) found I was unable to install magit, with the message:

Error (use-package): Failed to install magit: Package ‘graphql-0’ is unavailable
Error (use-package): Cannot load magit

I saw that there was a dependency of magit -> ghub -> graphql, which is why I'm opening this issue in this repo instead of magit. Let me know if that's wrong!

Can you advise me on what I am doing wrong, or how I might work around this issue?

[tarsius]

Thanks for the information. I didn't realize graphql wasn't available from Melpa yet. Luckily I have commit access and was therefore able to add it instantly. Could still take a few hours until the package becomes available though.

[joecox]

Thanks @tarsius for the quick response! I noticed the repo specified in melpa/melpa@9d911b7 gives a 404 (for me at least), will that cause problems?

[tarsius]

Yes 😁 Fixed.

[joecox]

Thanks @tarsius! I'll try in a few hours and close this issue if all goes well. 😃

[kalupa]

This looks like the github repo reference is incorrect in that melpa change.

Correct repo url is https://github.com/vermiculus/graphql.el

The melpa recipe references vermiculus/graphql

[npostavs]

It was is fixed in melpa/melpa@40dfd34 melpa/melpa@e555b46

[tarsius]

Okay, now it is fixed (and magithub also).

[tarsius]

Rebooting to Windows to play a game...

[creichert]

How long does it take for melpa to refresh?

[tarsius]

Current build started: 5 minutes ago, last took 2 hours

[slyrus]

And now this means that in order to use magit, I need ghub, which requires graphql, which require gq and yq? Holy ridiculous chained dependencies batman!

[vermiculus]

@slyrus I don't know of a dependency on any 'gq' (I don't even see a project by that name). I use yq to avoid duplication between the makefile and .travis.yml; it's not necessary to use graphql.el – only to test it locally (and only then if you really don't want to copy-paste the EMAKE_SHA1 hash from .travis.yml).

[slyrus]

Perhaps I'm using the wrong yq, but when I go to:

https://github.com/kislyuk/yq

I see:

pip install yq

Before using yq, you also have to install its dependency, jq. See the jq installation instructions for details and directions specific to your platform.

Ah, sorry. jq, not gq. but the point still applies :)

[vermiculus]

Original comment still stands: you don't need yq to use graphql.el :-)

[slyrus]

Ok, that may be true, even if it wasn't obvious to me. But now I need treepy. argh...

[vermiculus]

I still don't see why. Let's continue this conversation in chat; let's not spam folks with notifications :-) Post a message when you're in.

[slyrus]

I'll cease and desist complaining about dependencies but will add that the ghub makefile has the line:
DEPS += treepy
in it and attempting make in the ghub directory requires treepy -- which I was able to find and to use to successfully build so problem solved-ish. thanks!

[joecox]

Confirming fixed, thanks!

[tarsius]

The problem is that graphql's comes with an example.el file that has dependencies that graphql.el itself has not; so they may be unsatisfied. The result is that you may get an error, but the packages are still usable. But not all of them get compiled so that's still not good obviously.

I have updated the recipe to only include graphql.el. @vermiculus I would encourage you not to put any test and demo files at the top-level but instead use a subdirectory that contains a .nosearch file.

@vermiculus did not add any new dependencies to any of his packages so it's a bit silly to complain to him about new dependencies and being impolite about it.

I have added new dependencies to ghub, but ghub will soon cease to be a dependency of magit. In fact merging the things into ghub that added the additional dependencies was a step into that direction. It makes it easier for me to work on the new forge package. Once forge has been released, the parts of magit that depend on ghub can be re moved because forge provides better alternatives. Once that has happened, users can decide whether they want Github et al. integration and if and only if they do, then they can install forge. Avoiding potentially unnecessary dependencies is one of the major reasons why I am implementing the forge related functionality in a separate package (the other one being that the prefix forge- is more convenient than magit-SOMETHING-).

[vermiculus]

I would encourage you not to put any test and demo files at the top-level but instead use a subdirectory

I will move examples.el to a directory examples/. Does package-build automatically search all subdirectories for Lisp files? I've assumed that, by default, it would only search the top-level directory and ignore subdirectories like test/ and examples/ unless mentioned in the recipe specification.

[slyrus]

@tarsius and @vermiculus Apologies for being impolite. I was trying to be funny but I can see how that came across rudely. Thanks to all of you for your work on magit, ghub, etc...