10 ms·

Code Annotations for SourceHut

114 points by kragniz 7y ago

crispyporkbites 7y ago
Is SourceHut the new GitLab (which was the new GitHub)? This random HN commenter says yes!
- NetOpWibby 7y ago
  Easy installation instructions says no.
  - Sir_Cmpwn 7y ago
    https://man.sr.ht/installation.md https://man.sr.ht/installation.md
    - dewey 7y ago
      These are probably the opposite of what most people would call "Easy installation instructions" if you compare it to Gitlab's Omnibus package for example. They are well written and probably complete but not what people would call easy.
      - Sir_Cmpwn 7y ago
        I suppose at some point I can set up a Dockerfile, but understanding each of these pieces is necessary to maintain even a Gitlab installation, and definitely to scale one (and Gitlab requires scaling much sooner than SourceHut, which is far more lightweight). Handholding is not always the right answer.
svnpenn 7y ago
are they offering HTTPS yet - i would like to move away from GitHub if possible
- jefurii 7y ago
  It's been HTTPS from the beginning I believe.
- Sir_Cmpwn 7y ago
  I assume you're the same person I've been talking to on Lobsters. Clarification: they're talking about git push over https, which is deliberately unsupported in favor of the more secure SSH push option. git.sr.ht doesn't even have access to your password, so if the server is compromised then the attacker can't dump password hashes.
  - deleted 7y ago
    [deleted]
  - Nextgrid 7y ago
    If this is indeed the case could the parent comment explain why they prefer Git via HTTPS instead of SSH?
iso-8859-1 7y ago
How does this compare to using LSIF files? https://code.visualstudio.com/blogs/2018/12/04/rich-navigation https://code.visualstudio.com/blogs/2018/12/04/rich-navigati...
- Sir_Cmpwn 7y ago
  On SourceHut it's less language-aware and more generic, which makes it more useful for a wider range of use-cases. However, I could totally see a tool being possible which converts LSIF files into SourceHut annotations.
carapace 7y ago
Ooo! For Python dig up the old PySonar project (the author took it down for some reason but there are mirrors/archives where you can find versions. Oh hey, it looks like it has been resurrected: https://github.com/yinwang0/pysonar2 https://github.com/yinwang0/pysonar2) It might have been superseded by something else in the meantime, I dunno. It was the basis for Google's internal Python annotations thingy, and it fscking rocks.
0xDEFC0DE 7y ago
I'm embarrassed I didn't know <details>/<summary>/<ul>/<li> worked like that without javascript
asdkhadsj 7y ago
So excited to use this once my requirements are implemented (mostly just LFS, and to a lesser extent Merge(|Pull) Requests). Admittedly I don't need it, I just really appreciate the simplistic UI and straight forward pricing model.
- Sir_Cmpwn 7y ago
  LFS support is something I'd like to do, but It's Complicated(TM). Main challenges include finding a good place with ample bandwidth and storage, figuring out where/how to take backups of it, and measuring bandwidth and storage usage to integrate with billing. Not a priority right now, but may land between the beta and stable periods. As for merge requests, don't hold your breath. SourceHut embraces the email-based model. A tutorial is available here to give you an idea of how it works: https://git-send-email.io https://git-send-email.io and check out this video for the maintainer's side: https://aerc-mail.org/ https://aerc-mail.org/ The advantages of email include: - It's based on a venerable and well-understood standards, with ample open-source tooling available - It's decentralized, federated, and highly fault tolerant - It doesn't lock you into my platform, you have ownership over your content and can freely interact with projects anywhere It's also easy and natural to review code by writing emails, and by far the most efficient workflow for git collaboration I've used (having extensively worked in email, GitHub, GitLab, and Gerrit). I think you should give it a chance!
  - Nextgrid 7y ago
    My issue with emails is that the user experience isn't as good and while it can be a worthwhile tradeoff for the points you mention, most of them are irrelevant in an enterprise setting (think using an internal SourceHut server instead of self-hosted GitLab or Bitbucket Server) so the UX benefit would be very much welcome.
    - Sir_Cmpwn 7y ago
      I honestly disagree that the user experience isn't as good, and I don't think people have enough faith to try it out for a while. I've spent thousands of hours in many workflows and I still find email to be the easiest and most efficient way of doing it. However, I don't focus on the enterprise crowd, you're right about that.
imagiko 7y ago
Wondering if this is an alternative to some other lightweight git hosting services such as gitea/gogs. Good reason to consider switching?
- Sir_Cmpwn 7y ago
  Check out the marketing page: https://sourcehut.org https://sourcehut.org It has a nice summary of what's cool about it. It's very lightweight on the UI but it's actually very featureful, and includes mailing lists, CI service, etc.
Scaevolus 7y ago
These ideological decisions don't sound very pragmatic. There's a lot of open-source prior art in this space (OpenGrok, Kythe, SourceGraph) which provide support for most large languages and have annotation output formats that are broadly similar to this JSON file, and you could still support users having indexers for small languages running as part of CI. > There does not exist any widely available standalone C parsing library to provide C programs with access to an AST. There’s LLVM, but I have a deeply held belief that programming language compiler and introspection tooling should be implemented in the language itself. So, I set about to write a C parser from scratch. Even if you prefer to write your C indexer in C, you could use LLVM's C [1] or Python [2] APIs. Plus, you can handle C++ without having to implement your own C++ parser from scratch, which is a much larger undertaking than C99 plus a few GNU extensions. [1]: https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f19532b4e139d5f0a636d5c9/tools/c-index-test/c-index-test.c#L1956 https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f1... [2]: https://github.com/llvm-mirror/clang/blob/master/bindings/python/clang/cindex.py https://github.com/llvm-mirror/clang/blob/master/bindings/py...
- tptacek 7y ago
  Github also recently open-sourced their Haskell-based Semantic, which annotates and cross-references a whole bunch of languages (all the languages any of our clients use), and is built on tree-sitter, so there's, like, several levels of prior art available here.
  - iso-8859-1 7y ago
    Semantic is in Haskell, but since it doesn't use GHC, it cannot handle Haskell well (can't e.g. resolve type classes). If I wanted good code reviewing with Haskell, I figure it would be best to translate HIE files (https://www.haskell.org/ghc/blog/20190626-HIEFiles.html https://www.haskell.org/ghc/blog/20190626-HIEFiles.html) to LSIF (https://github.com/mpickering/hie-lsif https://github.com/mpickering/hie-lsif), which is supported in VSCode. Because of the limitations of only parsing, GitHub alone will not be as powerful. If I then just make an LSIF to SourceHut converter, SourceHut will have better annotations than GitHub...
  - 7y ago
woodrowbarlow 7y ago
if i get some time (unlikely, tbh), i'd love to take a crack at integrating your annotatec into sublime text 3 as a plugin.
nerdponx 7y ago
Wow, this is great! Conceivably someone could write an offline annotation viewer/editor as well? I would love for something like that to catch on. Imagine Emacs and Pycharm plugins for viewing and editing these annotations, for example.
- Sir_Cmpwn 7y ago
  Yep, you could. One thing which would be super cool is highlighting a snippet of code, entering an annotation, and having it uploaded to git.sr.ht right there.
deleted 7y ago
[deleted]

114 points by kragniz 7y ago

crispyporkbites 7y ago

Is SourceHut the new GitLab (which was the new GitHub)? This random HN commenter says yes!

NetOpWibby 7y ago
Easy installation instructions says no.
- Sir_Cmpwn 7y ago
  https://man.sr.ht/installation.md https://man.sr.ht/installation.md
  - dewey 7y ago
    These are probably the opposite of what most people would call "Easy installation instructions" if you compare it to Gitlab's Omnibus package for example. They are well written and probably complete but not what people would call easy.
    - Sir_Cmpwn 7y ago
      I suppose at some point I can set up a Dockerfile, but understanding each of these pieces is necessary to maintain even a Gitlab installation, and definitely to scale one (and Gitlab requires scaling much sooner than SourceHut, which is far more lightweight). Handholding is not always the right answer.

svnpenn 7y ago

are they offering HTTPS yet - i would like to move away from GitHub if possible

jefurii 7y ago
It's been HTTPS from the beginning I believe.
Sir_Cmpwn 7y ago
I assume you're the same person I've been talking to on Lobsters. Clarification: they're talking about git push over https, which is deliberately unsupported in favor of the more secure SSH push option. git.sr.ht doesn't even have access to your password, so if the server is compromised then the attacker can't dump password hashes.
- deleted 7y ago
  [deleted]
- Nextgrid 7y ago
  If this is indeed the case could the parent comment explain why they prefer Git via HTTPS instead of SSH?

iso-8859-1 7y ago

How does this compare to using LSIF files? https://code.visualstudio.com/blogs/2018/12/04/rich-navigation https://code.visualstudio.com/blogs/2018/12/04/rich-navigati...

Sir_Cmpwn 7y ago
On SourceHut it's less language-aware and more generic, which makes it more useful for a wider range of use-cases. However, I could totally see a tool being possible which converts LSIF files into SourceHut annotations.

carapace 7y ago

Ooo! For Python dig up the old PySonar project (the author took it down for some reason but there are mirrors/archives where you can find versions. Oh hey, it looks like it has been resurrected: https://github.com/yinwang0/pysonar2 https://github.com/yinwang0/pysonar2) It might have been superseded by something else in the meantime, I dunno. It was the basis for Google's internal Python annotations thingy, and it fscking rocks.

0xDEFC0DE 7y ago

I'm embarrassed I didn't know <details>/<summary>/<ul>/<li> worked like that without javascript

asdkhadsj 7y ago

So excited to use this once my requirements are implemented (mostly just LFS, and to a lesser extent Merge(|Pull) Requests). Admittedly I don't need it, I just really appreciate the simplistic UI and straight forward pricing model.

Sir_Cmpwn 7y ago
LFS support is something I'd like to do, but It's Complicated(TM). Main challenges include finding a good place with ample bandwidth and storage, figuring out where/how to take backups of it, and measuring bandwidth and storage usage to integrate with billing. Not a priority right now, but may land between the beta and stable periods. As for merge requests, don't hold your breath. SourceHut embraces the email-based model. A tutorial is available here to give you an idea of how it works: https://git-send-email.io https://git-send-email.io and check out this video for the maintainer's side: https://aerc-mail.org/ https://aerc-mail.org/ The advantages of email include: - It's based on a venerable and well-understood standards, with ample open-source tooling available - It's decentralized, federated, and highly fault tolerant - It doesn't lock you into my platform, you have ownership over your content and can freely interact with projects anywhere It's also easy and natural to review code by writing emails, and by far the most efficient workflow for git collaboration I've used (having extensively worked in email, GitHub, GitLab, and Gerrit). I think you should give it a chance!
- Nextgrid 7y ago
  My issue with emails is that the user experience isn't as good and while it can be a worthwhile tradeoff for the points you mention, most of them are irrelevant in an enterprise setting (think using an internal SourceHut server instead of self-hosted GitLab or Bitbucket Server) so the UX benefit would be very much welcome.
  - Sir_Cmpwn 7y ago
    I honestly disagree that the user experience isn't as good, and I don't think people have enough faith to try it out for a while. I've spent thousands of hours in many workflows and I still find email to be the easiest and most efficient way of doing it. However, I don't focus on the enterprise crowd, you're right about that.

imagiko 7y ago

Wondering if this is an alternative to some other lightweight git hosting services such as gitea/gogs. Good reason to consider switching?

Sir_Cmpwn 7y ago
Check out the marketing page: https://sourcehut.org https://sourcehut.org It has a nice summary of what's cool about it. It's very lightweight on the UI but it's actually very featureful, and includes mailing lists, CI service, etc.

Scaevolus 7y ago

These ideological decisions don't sound very pragmatic. There's a lot of open-source prior art in this space (OpenGrok, Kythe, SourceGraph) which provide support for most large languages and have annotation output formats that are broadly similar to this JSON file, and you could still support users having indexers for small languages running as part of CI. > There does not exist any widely available standalone C parsing library to provide C programs with access to an AST. There’s LLVM, but I have a deeply held belief that programming language compiler and introspection tooling should be implemented in the language itself. So, I set about to write a C parser from scratch. Even if you prefer to write your C indexer in C, you could use LLVM's C [1] or Python [2] APIs. Plus, you can handle C++ without having to implement your own C++ parser from scratch, which is a much larger undertaking than C99 plus a few GNU extensions. [1]: https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f19532b4e139d5f0a636d5c9/tools/c-index-test/c-index-test.c#L1956 https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f1... [2]: https://github.com/llvm-mirror/clang/blob/master/bindings/python/clang/cindex.py https://github.com/llvm-mirror/clang/blob/master/bindings/py...

tptacek 7y ago
Github also recently open-sourced their Haskell-based Semantic, which annotates and cross-references a whole bunch of languages (all the languages any of our clients use), and is built on tree-sitter, so there's, like, several levels of prior art available here.
- iso-8859-1 7y ago
  Semantic is in Haskell, but since it doesn't use GHC, it cannot handle Haskell well (can't e.g. resolve type classes). If I wanted good code reviewing with Haskell, I figure it would be best to translate HIE files (https://www.haskell.org/ghc/blog/20190626-HIEFiles.html https://www.haskell.org/ghc/blog/20190626-HIEFiles.html) to LSIF (https://github.com/mpickering/hie-lsif https://github.com/mpickering/hie-lsif), which is supported in VSCode. Because of the limitations of only parsing, GitHub alone will not be as powerful. If I then just make an LSIF to SourceHut converter, SourceHut will have better annotations than GitHub...
- 7y ago

woodrowbarlow 7y ago

if i get some time (unlikely, tbh), i'd love to take a crack at integrating your annotatec into sublime text 3 as a plugin.

nerdponx 7y ago

Wow, this is great! Conceivably someone could write an offline annotation viewer/editor as well? I would love for something like that to catch on. Imagine Emacs and Pycharm plugins for viewing and editing these annotations, for example.

Sir_Cmpwn 7y ago
Yep, you could. One thing which would be super cool is highlighting a snippet of code, entering an annotation, and having it uploaded to git.sr.ht right there.

deleted 7y ago

[deleted]