Hi,
The new version of RStudio [1] now bundles quarto [2], a publishing system written in JavaScript and TypeScript that in turn bundles Deno [3] (runtime written in Rust) and its standard library (this is not binary, but it's tagged independently of Deno at the moment), deno_dom, and Dart Sass (other binary dependencies are pandoc and esbuild, but they are part of Fedora already).
I'm a bit overwhelmed by this. Does anyone see any sane way forward here? Anyone willing to help? Some thoughts:
- We could package Deno, but how stable it is, and thus how important the tie to a specific version might be. Also, there's the question about how to handle its standard library and third-party modules. Maybe we could follow the same strategy as with nodejs, allowing bundling specific versions.
- Dart Saas seems quite complicated, because it obviously requires the Dart SDK [5]. Could Dart Saas be replaced by Ruby Saas?
[1] https://src.fedoraproject.org/rpms/rstudio [2] https://github.com/quarto-dev/quarto-cli [3] https://deno.land [4] https://github.com/sass/dart-sass [5] https://dart.dev/get-dart
On Fri, Feb 18, 2022 at 1:36 PM Iñaki Ucar iucar@fedoraproject.org wrote:
Hi,
The new version of RStudio [1] now bundles quarto [2], a publishing system written in JavaScript and TypeScript that in turn bundles Deno [3] (runtime written in Rust) and its standard library (this is not binary, but it's tagged independently of Deno at the moment), deno_dom, and Dart Sass (other binary dependencies are pandoc and esbuild, but they are part of Fedora already).
I'm a bit overwhelmed by this. Does anyone see any sane way forward here? Anyone willing to help? Some thoughts:
- We could package Deno, but how stable it is, and thus how important
the tie to a specific version might be. Also, there's the question about how to handle its standard library and third-party modules. Maybe we could follow the same strategy as with nodejs, allowing bundling specific versions.
I have tried packaging deno as RPMs. It is possible, but quite a big task.
The packages are now a bit out-of-date because I didn't have time to update them lately, but here's the work-in-progress .spec files for everything needed by deno: https://github.com/ironthree/deno-rpms and here's the work-in-progress RPM packages: https://copr.fedorainfracloud.org/coprs/decathorpe/deno/monitor/
The "deno" binary does work, but the packages would need working with upstream to fix some (mostly licensing) issues before they could be submitted as Fedora packages. (Note that building deno with vendored Rust dependencies would not really help, since those aforementioned issues would also need to be resolved in that case.)
- Dart Saas seems quite complicated, because it obviously requires the
Dart SDK [5]. Could Dart Saas be replaced by Ruby Saas?
I think the Ruby SASS gem is deprecated, I'd rather replace it with sassc. It is the recommended replacement, alongside the Dart library - but given that we don't have dart in Fedora, and we already have libsass / sassc, I'd try to use that instead.
Fabio
On Fri, Feb 18, 2022 at 2:30 PM Fabio Valentini decathorpe@gmail.com wrote:
On Fri, Feb 18, 2022 at 1:36 PM Iñaki Ucar iucar@fedoraproject.org wrote:
Hi,
The new version of RStudio [1] now bundles quarto [2], a publishing system written in JavaScript and TypeScript that in turn bundles Deno [3] (runtime written in Rust) and its standard library (this is not binary, but it's tagged independently of Deno at the moment), deno_dom, and Dart Sass (other binary dependencies are pandoc and esbuild, but they are part of Fedora already).
I'm a bit overwhelmed by this. Does anyone see any sane way forward here? Anyone willing to help? Some thoughts:
- We could package Deno, but how stable it is, and thus how important
the tie to a specific version might be. Also, there's the question about how to handle its standard library and third-party modules. Maybe we could follow the same strategy as with nodejs, allowing bundling specific versions.
I have tried packaging deno as RPMs. It is possible, but quite a big task.
The packages are now a bit out-of-date because I didn't have time to update them lately, but here's the work-in-progress .spec files for everything needed by deno: https://github.com/ironthree/deno-rpms and here's the work-in-progress RPM packages: https://copr.fedorainfracloud.org/coprs/decathorpe/deno/monitor/
The "deno" binary does work, but the packages would need working with upstream to fix some (mostly licensing) issues before they could be submitted as Fedora packages. (Note that building deno with vendored Rust dependencies would not really help, since those aforementioned issues would also need to be resolved in that case.)
Oh, and I forgot to mention: deno only supports building / running on x86_64 and aarch64. So if you need deno for anything, be aware that it's only available on those two architectures.
Fabio
On Fri, 18 Feb 2022 at 14:39, Fabio Valentini decathorpe@gmail.com wrote:
On Fri, Feb 18, 2022 at 1:36 PM Iñaki Ucar iucar@fedoraproject.org wrote:
Hi,
The new version of RStudio [1] now bundles quarto [2], a publishing system written in JavaScript and TypeScript that in turn bundles Deno [3] (runtime written in Rust) and its standard library (this is not binary, but it's tagged independently of Deno at the moment), deno_dom, and Dart Sass (other binary dependencies are pandoc and esbuild, but they are part of Fedora already).
I'm a bit overwhelmed by this. Does anyone see any sane way forward here? Anyone willing to help? Some thoughts:
- We could package Deno, but how stable it is, and thus how important
the tie to a specific version might be. Also, there's the question about how to handle its standard library and third-party modules. Maybe we could follow the same strategy as with nodejs, allowing bundling specific versions.
I have tried packaging deno as RPMs. It is possible, but quite a big task.
I was afraid this was the case. And then there is support only for x86_64 and aarch64, as you mentioned.
The packages are now a bit out-of-date because I didn't have time to update them lately, but here's the work-in-progress .spec files for everything needed by deno: https://github.com/ironthree/deno-rpms and here's the work-in-progress RPM packages: https://copr.fedorainfracloud.org/coprs/decathorpe/deno/monitor/
The "deno" binary does work, but the packages would need working with upstream to fix some (mostly licensing) issues before they could be submitted as Fedora packages. (Note that building deno with vendored Rust dependencies would not really help, since those aforementioned issues would also need to be resolved in that case.)
What kind of issues? Aren't they MIT licensed?
And when you talk about "packages" in this context, what does it mean? Are they parts of the main repo? Or third-party modules? I assume it's not what they call the "standard library", because that's JavaScript and TypeScript.
- Dart Saas seems quite complicated, because it obviously requires the
Dart SDK [5]. Could Dart Saas be replaced by Ruby Saas?
I think the Ruby SASS gem is deprecated, I'd rather replace it with sassc. It is the recommended replacement, alongside the Dart library - but given that we don't have dart in Fedora, and we already have libsass / sassc, I'd try to use that instead.
Ok, I see. I would need to check whether this can be a drop-in replacement.
Well, the deno part is quite a showstopper right now. I think we're stuck with the previous version of RStudio for now. :(
On Fri, Feb 18, 2022 at 3:14 PM Iñaki Ucar iucar@fedoraproject.org wrote:
What kind of issues? Aren't they MIT licensed?
Some of them are MIT licensed, some are not, but many do not correctly contain license files. I tried listing all the ones that don't in the TODO section on the GitHub repo I linked above.
And when you talk about "packages" in this context, what does it mean? Are they parts of the main repo? Or third-party modules? I assume it's not what they call the "standard library", because that's JavaScript and TypeScript.
I mean the packages for invidivual Rust dependencies. Some of them are part of the deno project (backend libraries for the "deno" runtime binary, which provide networking, crypto, filesystem access, etc. functionality for the runtime). But those also depend on a a lot of other Rust libraries, among them the dozens of crates that make up SWC (the typescript compiler they use), which is a separate project entirely The problems I see is that some crates do not publish sources with licenses files as they should, and one of the deno projects (rusty_v8) bundles sources for the V8 runtime from chromium, but doesn't include license files for all bundled components.
Fabio
On Fri, Feb 18, 2022 at 3:21 PM Fabio Valentini decathorpe@gmail.com wrote:
On Fri, Feb 18, 2022 at 3:14 PM Iñaki Ucar iucar@fedoraproject.org wrote:
What kind of issues? Aren't they MIT licensed?
Some of them are MIT licensed, some are not, but many do not correctly contain license files. I tried listing all the ones that don't in the TODO section on the GitHub repo I linked above.
And when you talk about "packages" in this context, what does it mean? Are they parts of the main repo? Or third-party modules? I assume it's not what they call the "standard library", because that's JavaScript and TypeScript.
I mean the packages for invidivual Rust dependencies. Some of them are part of the deno project (backend libraries for the "deno" runtime binary, which provide networking, crypto, filesystem access, etc. functionality for the runtime). But those also depend on a a lot of other Rust libraries, among them the dozens of crates that make up SWC (the typescript compiler they use), which is a separate project entirely The problems I see is that some crates do not publish sources with licenses files as they should, and one of the deno projects (rusty_v8) bundles sources for the V8 runtime from chromium, but doesn't include license files for all bundled components.
Sorry, hit send too soon.
Basically, maintaining a "properly done" package of deno for Fedora would be a full-time job, because of the sheer number of individual components, which also mostly need to be updated in a coordinated fashion. Which is why I only had time to do the initial packaging for COPR, and one big batch of updates, but then fell behind upstream releases, just because it's just so time-consuming.
Fabio
On 2/18/22 09:21, Fabio Valentini wrote:
On Fri, Feb 18, 2022 at 3:14 PM Iñaki Ucar iucar@fedoraproject.org wrote:
What kind of issues? Aren't they MIT licensed?
Some of them are MIT licensed, some are not, but many do not correctly contain license files. I tried listing all the ones that don't in the TODO section on the GitHub repo I linked above.
And when you talk about "packages" in this context, what does it mean? Are they parts of the main repo? Or third-party modules? I assume it's not what they call the "standard library", because that's JavaScript and TypeScript.
I mean the packages for invidivual Rust dependencies. Some of them are part of the deno project (backend libraries for the "deno" runtime binary, which provide networking, crypto, filesystem access, etc. functionality for the runtime). But those also depend on a a lot of other Rust libraries, among them the dozens of crates that make up SWC (the typescript compiler they use), which is a separate project entirely The problems I see is that some crates do not publish sources with licenses files as they should, and one of the deno projects (rusty_v8) bundles sources for the V8 runtime from chromium, but doesn't include license files for all bundled components.
Fabio
Please report bugs against the crates in question. This is an upstream problem, not yours.