Add BuildStream to Linguist: https://github.com/github/linguist #1351

Open BuildStream-Migration-Bot opened 3 years ago

See original issue on GitLab In GitLab by [Gitlab user @frazerclews] on Jul 6, 2020, 19:28

Background

//: # BuildStream doesn't show up in GitLab, GitHub, etc repositories which doesn't help it being well known. And would help those getting into a BuildStream project a better understanding of the project. Since BitBake is in the linguist list, I am sure BuildStream can be too

Task description

[ ] Add BuildStream following linguists steps https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language
[ ] Use YAML as the grammar for BuildStream

Acceptance Criteria

//: # Having BuildStream show up along side other languages in GitHub, GitLab, etc projects, and hopefully have BuildStream have grammatical highlighting if we use the YAML grammar already in linguist

In GitLab by [Gitlab user @frazerclews] on Jul 6, 2020, 19:29

changed title from Add BuildStream to {-Linguist-} to Add BuildStream to {+<Linguist>+}

In GitLab by [Gitlab user @frazerclews] on Jul 6, 2020, 19:30

changed title from Add BuildStream to {-<Linguist>-} to Add BuildStream to {+Linguist: https://github.com/github/linguist+}

In GitLab by [Gitlab user @sstriker] on Jul 7, 2020, 21:36

I'm a bit torn on this one. I don't think that

BuildStream doesn't show up in GitLab, GitHub, etc repositories which doesn't help it being well known.

is a good enough reason - that is, we shouldn't think of Linguist as a marketing-tool.

I also think the reasoning is a bit backwards. Quoting from https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language:

We try only to add languages once they have some usage on GitHub. In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

I don't think we can honestly claim that yet.

While the comparison with BitBake, which has been around since 2004, may seem to make sense at a high level, I tend to think BuildStream is a different beast. Especially looking at the BitBake syntax.

In GitLab by [Gitlab user @cs-shadow] on Jul 8, 2020, 10:14

that is, we shouldn't think of Linguist as a marketing-tool

+1

Perhpas I skimmed through the actual description without much care, but my original reading of this issue was more that .bst files do not get syntax highlighting on code hosting sites like GitHub, GitLab etc. Personally, I do think this is important for developer producitivity but doesn't necessarily have to be solved in Linguist itself.

If that was indeed the motivation behind this, it may be worth mentioning at least GitHub and GitLab support language hints via .gitattributes:

GitHub: https://github.com/github/linguist#using-gitattributes
```
*.bst linguist-language=YAML
```
GitLab: https://docs.gitlab.com/ee/user/project/highlighting.html
```
*.bst gitlab-language=yaml
```

Also, for one off .bst snippets, one can also use vim/emacs style syntax highlight hints. Most code hosting sites support these already.

In GitLab by [Gitlab user @frazerclews] on Jul 11, 2020, 13:33

It wasn't the idea of using it as a marketing tool, the intention is to get those getting into a project that uses BuildStream less confused, while maybe also providing benefits like syntax highlighting using the YAML grammar. When I first heard of BuildStream, I didn't think of a language, mainly because it didn't show up as one and made things quite confusing. I also understand the issue with the GitHub library not being large enough, but personally I feel it should expand to GitLab instead of just GitHub, especially as a lot of people are moving towards GitLab and other services like there own GitLab instance now, and it's not good to just stick to one service where Linguist is used a lot outside of GitHub. This is something I have brought up with the team and I am waiting for a response.

In GitLab by [Gitlab user @frazerclews] on Jul 11, 2020, 13:40

Personally I find syntax highlighting very useful, and I feel just adds a level of polish which helps in the long run. .gitattributes could definitely work in the short term, but I feel it's just putting more work on a team whenever they use a BuildStream project and enforce consistency with all BuildStream projects that may not know about that or be bothered to do it due to time constraints, and would mess up things if developers fork it to different services

In GitLab by [Gitlab user @cs-shadow] on Jul 17, 2020, 13:32

would mess up things if developers fork it to different services

I'm not sure how Linguist would solve this though. There are a plethora of code hosting services and linguist is far from being the ubiquitous tool for this job. We don't have to look too far to find examples of sites that don't use Linguist. Take GitLab for instance, it uses rogue to do syntax detection and highlighting.

apache / buildstream