My low-priority TODO list for luapower


    • test website on IE 10

    BUGS

    • specify and/or infer package type: eg. what type is luajit? what type is bundle? (add a new "system" type?)
    • add website/download/clone section "Additional packages for running tests & demos"

    Steps towards automated unit testing

    luapower can be easily extended to run automated tests and record their results in luapower_db.lua for displaying them on the website. For that, some tests need to be made more substantial, and maybe even incorporate an "official" unit testing library.

    • tests that are not really testing anything (but fast and don't crash):
      bitmap_test
      freetype_test
      fribidi_test
      harfbuzz_test
      lexer_test
    • replace 'unit' with a proper unit testing library
      • busted
      • gambiarra
      • luaunit
      • shake even?
    • luapower: run *_test scripts, and record test results and errors in luapower_db

    Separate module directories

    Make a luapower mode in which modules are cloned in their own separate directories, for people who are intimidated by the overlaid model and/or multigit. This is very simple to do with luapower's current design, up to the problem of loading binary dependencies of shared libraries, which is an annoyingly hard problem because there's no API for getting those at runtime (and we would like to avoid having a pre-generated list of dependencies). Here's the todo list:

    • "luapower runtime" package (git clone https://github.com/luapower/luapower-rt)
      • simple clone/list/clone-all command
      • luajit wrappers with -lluapower_rt
      • luapower_rt.lua
        • require() package loader
          • detect module's package using name heuristics just like luapower
            • fallback to scanning all package directories
              • ignore .git, csrc, media, bin
        • patch ffi.load() to pre-load dependencies
          • find dependencies via low-overhead mini-pe/elf/mach parser
          • find dependencies via pre-generated dependency file (bleah)
    • extend luapower.lua to support this mode
    • extend mgit tools from luapower-repos to support this mode
    • provide a launcher for said mgit tools
    • extend bundle.sh to support this mode

    Depdendency tracking for apps

    Use luapower to track dependencies of any luapower app and generate a mgit bundle command out of that for bundling, and a mgit clone command for git-based deployment.

    • start/stop tracking
    • generate bundle command line
      • check for availability of: modules, static libs, dynamic libs
      • report extra libs and modules that are not in the luapower tree
    • generate mgit clone command line in two flavors: simple and versioned

    Separate out tests + demos + media files in *-test packages

    • Q: separate binaries too? separate platforms too? we'd have N*6 packages...
    • Q: make a diff. branch or a diff. repo?
      • if branch, how easy it is to work with branches in git / mgit? (it's easier to work with separate repositories, but then maybe we don't want separate histories in this case)
    • luapower:
      • test_package(pkg) -> pkg
      • module_packages() <- known - installed - not-test packages
    • website:
      • use module_packages() instead of installed_packages()
      • download: test package - separate button, separate clone section

    Website homepage download buttons

    It would be cool if daily bundles would actually be tagged releases, made automatically whenever a package changes. This way they won't be updated on the days when no package is updated (hard to imagine), and old releases will also be preserved and available for download as well.

    • make daily lock files (compare to the last lock file/ignore if identical)
    • make tag lockfiles (same algorithm)
    • make zip bundles based on just-made lockfile
    • make drop-down buttons which select old releases
    • make daily binary bundles with everything included

    Website code browser

    Github's code browser is cool, but it can be way cooler:

    • navigation on require"<module>"
    • parse definitions and make an in-memory database
    • navigate to symbols from other modules
    • literate-style view

    Luapower rockspec generator

    • how to register origins of dependencies
    • Lua/C module paths must be for the right platform

    Infer binary dependencies

    Extending luapower to infer binary dependencies is the last step towards all-convention and no-configuration packages. This can be done:

    • by calling mgit syms -l libname (already implemented)
    • by parsing the PE, MACH and ELF formats
      • there's a Lua pe-parser and an elf parser (no mach parser?)

    Multigit branches

    Multigit doesn't currently have any support for branches.

    • allow branch in clone url syntax: [ORIGIN/]REPO|URL[=[BRANCH:]VERSION]
      • how about repo=branch:v2,tag:r5-5-567adf or repo(v2)=tag:r5-5-567adf
    • allow checking out a diff. branch from the same package under a diff. name?
      • mgit clone pkg1 --as p1 pkg2 --as=p2
      • limited use: only for branches that have no files in common (eg. gh-pages)
      • implication: add REMOTE|URL=BRANCH: syntax in .origin files

    Automate website maintenance

    • check broken links (incl. redirects to homepage)
    • check new lib versions periodically and report them via email
      • versioneye could do this for us for free, if we generate a package file in a supported format (pom.xml, dependency.gradle, build.sbt, Gemfile, Gemfile.lock, requirements.txt, setup.py, package.json, composer.json, composer.lock, Podfile, Podfile.lock and project.clj)

    Research on package managers


  • 1
    Posts
    743
    Views
    Log in to reply

Internal error.

Oops! Looks like something went wrong!