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

Allow packages from sources other than GitHub #422

Open
f-f opened this issue Sep 28, 2020 · 7 comments
Open

Allow packages from sources other than GitHub #422

f-f opened this issue Sep 28, 2020 · 7 comments

Comments

@f-f
Copy link
Member

f-f commented Sep 28, 2020

Moving over here from purescript/registry#15, which mentions that the only problems of allowing packages to be published from sources other than GitHub come from Pursuit relying on GitHub for some things. Quoting from there:

Right now Pursuit only supports packages hosted on GitHub, and nobody has complained [..]. The reasons for this are that allows us to use the GitHub API to get a rendered HTML readme (although I now consider that a misfeature and I'd like to remove it), and also it allows us to construct source links, since the source links take you to GitHub. If we allow non-GH packages in the registry, this means we won't be able to upload those packages to Pursuit right now (which is not a dealbreaker but probably worth considering). I'd quite like to have package sources hosted in the same place as the HTML API docs for source links though, which will probably be easier to do now with our shiny new registry; if we did that we'd be able to allow non-GH packages without losing source links.

@f-f f-f changed the title Allow package from other sources other than GitHub Allow packages from other sources other than GitHub Sep 28, 2020
@f-f f-f changed the title Allow packages from other sources other than GitHub Allow packages from sources other than GitHub Sep 28, 2020
@toastal
Copy link

toastal commented Aug 21, 2021

For Sourcehut you can get users and rendered README in one fell swoop through their GraphQL API (schema).

query {
 repositoryByName(name: "purescript-web-page-visibility") {
    name
    readme
    owner { id }
    description
  }
  user(username: "toastal") { id username }
}

Which returns something like

{
  "data": {
    "repositoryByName": {
      "name": "purescript-web-page-visibility",
      "readme": "$ESCAPED_README_AS_HTML",
      "description": "Type definitions and low level interface implementations for W3C Page Visibility API",
      "owner": {
        "id": 11755
      }
    },
    "user": {
      "id": 11755,
      "username": "toastal"
    }
  }

Querying through cURL is something like

$ oauth_token=your oauth token
$ curl \
  --oauth2-bearer "$oauth_token" \
  -H 'Content-Type: application/json' \
  -d '{"query": "{ version { major, minor, patch } }"}' \
  https://meta.sr.ht/query

with full documentation.

If I was more familiar with Haskell (and by that I mean getting tooling set up and working), I would work on this.

@hdgarrood
Copy link
Collaborator

Rather than maintaining numerous integrations, I’d rather have Pursuit know as little as possible about the various code hosting services there are. In particular I would rather move in the direction of having the JSON upload contain Markdown which will be rendered by Pursuit itself instead of using APIs to render readmes. See #150 (comment)

@toastal
Copy link

toastal commented Aug 21, 2021

Oh, I wouldn't disagree, but now you definitely need to have your own sanitizer. One of my quibbles with GitHub's Markdown renderer, is that it removes <abbr> tags that add to accessibility, but if you let in script tags and who knows what else, that could be a concern (I assume this was 100% already thought about though).


One thing I appreciate about Sourcehut is that through their GraphQL API, you can POST any sort of HTML -- BYOR, bring your own renderer. Similar to not relying on a singular Git forge, you're also not relying on a markup language. Markdown has no specific spec really and is quite limiting for many application. In my own case, I ran asciidoctor from my Nix Flake package and had the build system cURL POST the rendered HTML output. I would personally say BYOR is preferable -- use reStructuredText or Org Mode or whatever lightweight markup suits you.

@hdgarrood
Copy link
Collaborator

Yes, we already have a sanitiser, for rendering the markdown in doc-comments. The problem with allowing people to bring their own renderer is that you then have to account for any kind of dodgy HTML they might produce. We can already sanitise markdown, but sanitising HTML is harder.

@toastal
Copy link

toastal commented Aug 21, 2021

Then will you bring a Markdown flavor that supports tables, abbreviations, admonitions, imports, and more out-of-the-box features? That's my biggest concern more than syntax A vs syntax B.

@hdgarrood
Copy link
Collaborator

No - this is just for the package’s readme on Pursuit. If you need all those things, I’d suggest setting up a separate documentation site.

@toastal
Copy link

toastal commented Aug 21, 2021

Ah, that is reasonable 🖖 (this said, abbreviation support I think is a good accessibility feature)

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

No branches or pull requests

3 participants