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

Surface reason for git authentication failures #2625

Open
BioTurboNick opened this issue Aug 3, 2023 · 5 comments
Open

Surface reason for git authentication failures #2625

BioTurboNick opened this issue Aug 3, 2023 · 5 comments
Labels
enhancement New feature or request package manager Pluto's built-in package manager

Comments

@BioTurboNick
Copy link
Contributor

BioTurboNick commented Aug 3, 2023

If you have a private repository that you normally access with SSH credentials (git@github.com:), but instead try to load with username/password (https://github.com/), the request by GitHub for those credentials (hidden on stdout) causes a crash loop with the notebook.

To reproduce, probably need a LocalRegistry, to which you add a dummy package from a private repository.

Then add both the General and local registry to Julia.

Then open a notebook and try to load the private package using the Pluto package manager (just a normal using statement). May need a General package to be listed first - should quickly see an error saying it can't find the package and a Restart Notebook banner.

image

So it would be good to surface the fact that git itself encountered a problem and can't run without intervention.

(Deleted a bit about affecting other notebooks - that was a coincidence :-) )

@BioTurboNick BioTurboNick changed the title Isolate git authentication failures to single notebook, surface reason for error Surface reason for git authentication failures Aug 3, 2023
@Pangoraw Pangoraw added the enhancement New feature or request label Aug 13, 2023
@fonsp
Copy link
Owner

fonsp commented Aug 10, 2024

hey @BioTurboNick sprry for the late reply!

Pluto uses Pkg (and RegistryInstances.jl) for this. Which Pkg call do you think caused the error?

You could take a look at our packagae management code, everything should be behind a try catch. But maybe not the code that loads in the registries?

@fonsp fonsp added the package manager Pluto's built-in package manager label Aug 10, 2024
@BioTurboNick
Copy link
Contributor Author

BioTurboNick commented Aug 13, 2024

Unfortunately I haven't seen this issue in a long time. I just tried to reproduce it and I think it fails safe now, though perhaps could still be room for some improvement down the line?

Now, it produces this stdout:

     Cloning git-repo `https://github.com/<username>/<repo>`
fatal: could not read Username for 'https://github.com': No such device or address

Which results in this error:
image

Perhaps the username request or failure could be detected, and Pluto could inform the user that a package requested git authentication, and direct people to solutions (e.g. use SSH).

@fonsp
Copy link
Owner

fonsp commented Aug 14, 2024

Hey @BioTurboNick !

In your last comment, you used a Pkg.add call inside a cell. In that case, the error message displayed in the notebook comes from Pkg.jl, and it's the same as in the REPL, right? (So you could contribute improvements directly to Pkg.jl and they will show up in Pluto?)

I just noticed that your original post has no checkmarks next to package names, so you are not using the Pluto package manager because you use Pkg.activate. If you are not using the Pluto package manager, then all behaviour and error messages should be exactly as in the REPL, originating from Pkg.jl. I don't think there is something actionable from the Pluto side, or?

@BioTurboNick
Copy link
Contributor Author

BioTurboNick commented Aug 16, 2024

It's just a bit unique in that a better error in the REPL is somewhat extraneous because user action would happen and the user would know what they did.

But maybe the status quo is livable. It does seem like the git request is now displayed in the stdout display, which wasn't the case before. Maybe a broader issue is if there's a need to handle terminal input requests in some way? Not necessarily to provide an interface for it, but to flag for the user that interactive input was requested and this isn't possible in Pluto?

@fonsp
Copy link
Owner

fonsp commented Aug 17, 2024

Ah sorry I only fully understand it now: it's about unsupported stdin.

Could you check if it's possible to detect an attempt to use stdin? I suspect not, especially if it comes from the git subprocess. Not sure how much of this code is in Julia.

Otherwise, there is still some value in improving the error message: it would also help when running julia in CI, or on a headless server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request package manager Pluto's built-in package manager
Projects
None yet
Development

No branches or pull requests

3 participants