Add support for the reStructuredPython programming language and the REPY sandbox enviornment

[sharktide]

Add language support for reStructuredPython and the REPY sandbox environment since they are both subsets/supersets of python and deserve their own language highlighting for the two reasons:

1. People get really mad and don't put their code on GitHub because it isn't highlighted and recognized
2. These languages are really not regular python
3. It has enough popularity (in and out of github)

Description

Checklist:

• I am adding a new language.
  • The extension of the new language is used in hundreds of repositories on GitHub.com.
    • Search results for each extension:
      • https://github.com/search?type=code&q=NOT+is%3Afork+path%3A.repy
  • I have included a real-world usage sample for all extensions added in this PR:
    • Sample source(s):
      • https://github.com/sharktide/recipe-api.git (app.repy)
    • Sample license(s): MIT
  • I have included a syntax highlighting grammar: https://github.com/sharktide/repython-vs.git
  • I have added a color
    • Hex value: #3289a8
    • Rationale: Same color as the language logo
  • I have updated the heuristics to distinguish my language from others using the same extension.
    Not Applicable

[lildude]

It has enough popularity (in and out of github)

It definitely doesn't. It is miles away from our requirements.

[sharktide]

@lildude

It has enough popularity (in and out of github)

It definitely doesn't. It is miles away from our requirements.

For public repositories, it is miles away, but that is kinda expected: people won't put these in public repositories for these two reasons

• The REPY sandbox environment is mostly used to execute beta/untrusted code in restricted envoirnments, so developers might not have wanted their code public. Also, due to licensing issue(s) developers might've opted to keep their code private instead.
• reStructuredPython is a compiled language (like TypeScript), but people have no incentive to push to public repositories because there coincidentally is no syntax highlighting from linguist on github!

for popularity: the download stats for restructuredpython: https://pypistats.org/api/packages/restructuredpython/overall should be enough. I totaled it for you:

with_mirrors: 5,388 downloads
without_mirrors: 2,173 downloads

Total: 7561 downloads.

TD;LR: In github popularity: probably not in that many public repos. Out of github: exceeds the popularity requirements (IMO)

It would save a lot of people a lot of time to just at least recognize the syntax highlighting, and in that case why not recognize it?

I think this might be an edge case, but maybe I am biased so what do you think :)

[lildude]

Public popularity on GitHub is the only measure we use (we don't have exposure to private repo code so can analyse this) and third-party stats and things like download stats have no impact on how the code is used on GitHub. This has been the case since we introduced this requirement, with no exceptions. You can see this from the PRs we have open with this tag and many closed or finally merged in the past.

If we relax this policy for one we have to do it for all, including every hobby language that someone thinks of in their spare time.

And on that topic, if https://github.com/sharktide/restructuredpython is the language repo, it indicates the language is less than three months old which means this PR may be a little premature and this language could still be considered a hobby language and may never meet our requirements.

[sharktide]

@lildude

Okay, that makes sense.

This PR is probably premature, but considering the growing popularity and the fact I asked some people I know to put their code on github/public it should only take a few weeks to months.

P.S.

https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.repy was the wrong link

it actually is this: https://github.com/search?type=code&q=NOT+is%3Afork+path%3A.repy

It put an extra * in there. Anyway, I asked some people I know to put their code on github, so that is why it may seem strange why so many new files start popping up.

Anyway 924/2000: Thats 46%.

*Sorry for being annoying in my comments I didn't mean it I promise :)

Also, any idea on the test failuers?

[lildude]

Also, any idea on the test failuers?

Yup. Looks like the LiveScript grammar has been removed:

Error updating vendor/grammars/LiveScript.tmbundle
Cloning into '/home/runner/work/linguist/linguist/vendor/grammars/LiveScript.tmbundle'...
fatal: could not read Username for 'https://github.com/': No such device or address
fatal: clone of 'https://github.com/paulmillr/LiveScript.tmbundle' into submodule path '/home/runner/work/linguist/linguist/vendor/grammars/LiveScript.tmbundle' failed
Failed to clone 'vendor/grammars/LiveScript.tmbundle'. Retry scheduled
Cloning into '/home/runner/work/linguist/linguist/vendor/grammars/LiveScript.tmbundle'...
fatal: could not read Username for 'https://github.com/': No such device or address
fatal: clone of 'https://github.com/paulmillr/LiveScript.tmbundle' into submodule path '/home/runner/work/linguist/linguist/vendor/grammars/LiveScript.tmbundle' failed
Failed to clone 'vendor/grammars/LiveScript.tmbundle' a second time, aborting

You can ignore this failure for now.

@paulmillr - whoopsie, we still need this grammar.

[paulmillr]

@lildude can’t help with that

[lildude]

@lildude can’t help with that

But you owned the repo until very recently. Do you have an another source for the language's grammar?

If not we'll have to remove the grammar which will remove syntax highlighting. This will be highlighted in the release notes and thus indirectly attributed to you.

[paulmillr]

I don’t think anyone cares about livescript these days.

[lildude]

I don’t think anyone cares about livescript these days.

@paulmillr That may be the case, but there is still code on GitHub and people will notice and complain. Your grammar is also referenced on the LiveScript site at https://livescript.net/#editor-support

[paulmillr]

@lildude i don’t care - if github cares it should have forked all grammars. Any repo on github can get deleted at any moment. I certainly am not going to support the grammar.

Please unsub me from this convo.

[sharktide]

Since @paulmillr is clearly not going to do it. I can create a new grammar repo. It might look different, but it should be semi-functional. @lildude what do you think

[sharktide]

New grammar repo: http://github.com/sharktide/livescript-vscode.git

@lildude The syntax highlighting in it is ready to be implemented.

[lildude]

Please unsub me from this convo.

@paulmillr Only you can do that… using the button specifically for it in the sidebar

New grammar repo: http://github.com/sharktide/livescript-vscode.git

@lildude The syntax highlighting in it is ready to be implemented.

Thanks @sharktide That's generous of you. If you prefer not to maintain a grammar for a language you're not familiar with, I've found there's a VSCode grammar at https://github.com/tientq64/livescript-vscode which should do the trick.

If you want to do the switcheroo, you can find details in the CONTRIBUTING.md file, else I'll try find time for it next week.

[sharktide]

Please unsub me from this convo.

@paulmillr Only you can do that… using the button specifically for it in the sidebar

New grammar repo: http://github.com/sharktide/livescript-vscode.git
@lildude The syntax highlighting in it is ready to be implemented.

Thanks @sharktide That's generous of you. If you prefer not to maintain a grammar for a language you're not familiar with, I've found there's a VSCode grammar at https://github.com/tientq64/livescript-vscode which should do the trick.

If you want to do the switcheroo, you can find details in the CONTRIBUTING.md file, else I'll try find time for it next week.

I can maintain it; I am familiar with JavaScript and TypeScript, and livescript is also up my alley. Do you which files to delete the old urls to the old livescript grammar and then update it to mine? (I just need to know ehere to delete it from, so I can rerun the script/add-grammar. My branch for it: https://github.com/sharktide/linguist/tree/livescript-grammar-2

[lildude]

https://github.com/tientq64/livescript-vscode might do the trick.

I can maintain it; I am familiar with JavaScript and TypeScript, and livescript is also up my alley. Do you which files to delete the old urls to the old livescript grammar and then update it to mine? (I just need to know ehere to delete it from, so I can rerun the script/add-grammar. My branch for it: https://github.com/sharktide/linguist/tree/livescript-grammar-2

You don't need to delete anything yourself. Follow the instructions for replacing a grammar in the CONTRIBUTING.md file. The script/add-grammar does it all for you.

[sharktide]

https://github.com/tientq64/livescript-vscode might do the trick.

I can maintain it; I am familiar with JavaScript and TypeScript, and livescript is also up my alley. Do you which files to delete the old urls to the old livescript grammar and then update it to mine? (I just need to know ehere to delete it from, so I can rerun the script/add-grammar. My branch for it: https://github.com/sharktide/linguist/tree/livescript-grammar-2

You don't need to delete anything yourself. Follow the instructions for replacing a grammar in the CONTRIBUTING.md file. The script/add-grammar does it all for you.

should I ask tientq64 first? I don't know if they'll reply in time though. The repo hasn't been maintained for a year, so I will commit my highlighting temporarily, until you tell me if I should raise an issue on the repo of tientq64 asking for permission

I couldn't think of a better way to say it, I mean that idk if we have to ask permission or notify the owner before using it in the grammar submodules

[sharktide]

Adressing test failures

[sharktide]

@lildude I just realized that this actually does fit the requirements!

A .repy file is typically used only once or twice per repository.

One .repy file for node behavior

One for a utility or service (rarley)

But you wouldn't typically have many .repy files all depending on each other or reused broadly across modules.

Execution style: .repy scripts are executed by the Repy runtime (repy.py), not usually imported as modules. So the usage is closer to standalone tools or configuration scripts.

Security and isolation: Because Repy emphasizes sandboxing, most .repy scripts avoid shared state or cross-imports, which discourages heavy reuse.

Typical Usage in a Repo:
main.repy: primary logic

nodemanager.repy: node controller logic (again, rarely)

That’s usually about it.

Same for restructuredpython --> best used for simple APIs, AI model training, etc, where you have one-file programs.

eg. look at https://github.com/sharktide/eshare or this gist https://gist.github.com/sharktide/e367ed50e09bb4d4f7a826516cf58c12

Essentially, since we have a one-file repo scenario, this fits all the requirements, and looking at search results we have 950+ so this means it can be merged, all within the rules!

[sharktide]

@lildude please see my previous comment.