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

Request Roku for official compiler support for roku_modules #7

Open
TwitchBronBron opened this issue Aug 11, 2020 · 2 comments
Open

Comments

@TwitchBronBron
Copy link
Member

TwitchBronBron commented Aug 11, 2020

Proposal for roku_modules on the Roku platform

Many platforms have package managers (e.g. npm, nuget, cocoapods) that allow developers to share code. The Roku developer community has created a package manager named ropm.

This allows developers to easily import code modules into their roku channel store projects. e.g.

  • ropm install sgdex
  • ropm install roku-unit-testing-framework
  • ropm install adbmobile-roku
  • ropm install bitmovin-roku
  • etc

The response from the community is very enthusiastic, and many teams are excited about the improved collaboration and further innovation they will experience, as they do on other platforms with simple code sharing mechanisms e.g.: Apple, Google and Web.

The problem

Roku has a code library sharing mechanism, which works great for small and specific use cases (e.g. raf, google ima, etc); but this system isn't suited to general code sharing, so developers have to manage their 3rd party code sharing manually.

When including third party libraries, many manual steps need to be taken, due to the "special" folders in a Roku application:

  • pkg:/source/ which compiles every function from all .brs files together into a single scope
  • pkg:/components/ which compiles every component from all .xml files into the component registry

Consider the documentation taken straight from Roku's Scene Graph Developer Extensions

  • Copy the SGDEX folder into your channel so that the path to the folder is pkg:/components/SGDEX. This path is required for certain graphic elements to work correctly.
  • Copy SGDEX.brs into your channel so that the path to the file is pkg:/source/SGDEX.brs
  • Add this line to your manifest: bs_libs_required=roku_ads_lib

This can be undesirable when considering projects may include 5-10 third party libraries (e.g. analytics frameworks, unit testing, ui frameworks, custom video players, network/other helpers, etc). A developer must:

  • Manually install each third party library
  • Differentiate between application code and the third party code
  • Manage any naming collisions/filename/filepath collisions

This also has a detrimental effect on code sharing: these difficulties demotivate developers from sharing their code with one another, negatively impacting the community as a whole.

Proposal

We propose that the Roku compiler should support another "special" folder: roku_modules. The Roku compiler will apply the following algorithm to folders inside of pkg:/roku_modules/:

  • iterate over every direct child folder of pkg:/roku_modules (i.e. pkg:/roku_modules/sgdex/, pkg:/roku_modules/rokupromise).
    • for every source/ folder found, compile it in the same way as pkg:/sources (i.e. add all functions to the source scope)
    • for every components/ folder found, compile it in the same way as pkg:/components (i.e. add all components found to the global in-memory component registry)

Here's some pseudocode for how the compiler might handle this:

if (directory_exists('pkg:/roku_modules'){

    var childDirectories = getImmediateChildDirectories('pkg:/roku_modules');
    
    for (var childDirectory of childDirectories) {
    
        if (directory_exists("pkg:/roku_modules/" + childDirectory + "/source") {
    
            //call existing compiler function for `source` scope
            compileDirAsSourceScope("pkg:/roku_modules/" + childDirectory + "/source")
        }

        if (directory_exists("pkg:/roku_modules/" + childDirectory + "/components") {
    
            //call existing compiler function for compiling components
            compileDirAsComponents("pkg:/roku_modules/" + childDirectory + "/components")
        }
        
    }
}

Benefits:

  • All third party code can be stored in a separate folder from the main application code
  • This generic approach does not tie the compiler to any specific community tool
  • Should be relatively simple to implement in the compiler
  • The roku_modules folder name is very unique, so there is minimal concern for breaking backwards-compatibility in the compiler. (I'm sure you could run some metrics against all published applications to verify)
  • Developers can have sophisticated code sharing, that they are used to from other platforms, without being constrained to the current Roku library mechanism

ropm (roku package manager) and roku community

We are all passionate developers on the roku platform with a mission to improve the day to day lives of others as well as ourselves, and make it easier to produce great work. We acknowledge that the sharing of code modules is fundamental to a vibrant developer community.

As such, we have already created ropm, which you can try today (in early alpha). We already know that teams and popular open source projects are going to start using ropm. The downside to the current ropm approach is that ropm must copy files manually into subfolders of the main project in order to properly utilize the special "pkg:/source" and "pkg:/components" folders.

Having compiler support, as laid out above, will greatly improve the experience for everyone in the Roku community. We truly hope Roku will help us in this endeavor.

@chrisdp
Copy link

chrisdp commented Aug 11, 2020

This would be a game changer for many of us in the Roku Community!

@oscarsanchez
Copy link

As an active developer making daily use of SGDEX, Adbmobile and many other 3rd party libraries I really hope this can become a reality!

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