├── README.md └── docs ├── _config.yml ├── flaws.md ├── ideas.md └── index.md /README.md: -------------------------------------------------------------------------------- 1 | # 🌠Meteor 2 | 3 | Discord 4 | 5 | A package manager exploration project for Lua. Last revised on **January 2021**. 6 | 7 | ## What? 8 | 9 | It's too early to call this an alternative package manager for Lua, so I will be calling this a *package manager exploration project*. The point is looking at what LuaRocks does right, what it does wrong, what could improve and what is completely missing. 10 | 11 | ## Why? 12 | 13 | LuaRocks is the choice package manager for Lua, and the one everyone uses for distributing packages. It's not a bad package manager, but it has its flaws. 14 | 15 | ## How? 16 | 17 | This repository will mostly contain text for a while. First I would like to collect ideas, input from the community, see what we can do, what we should do, and things like that. 18 | 19 | ## Where? 20 | 21 | Check out the concept, ideas and other things [here](//git.daelvn.com/meteor/). 22 | -------------------------------------------------------------------------------- /docs/_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-minimal -------------------------------------------------------------------------------- /docs/flaws.md: -------------------------------------------------------------------------------- 1 | ## Flaws 2 | 3 | In this document, I just describe some of the shortcomings I see in LuaRocks: things I'd like to improve, really. 4 | 5 | ### Clear and useful errors 6 | 7 | It's not uncommon to get an error such as `file source and destination cannot be the same` to tell you that the file does not actually exist. At one point, you get used to this, but I think the error messages are not user-friendly at all. They are not descriptive enough and often leave you going in circles or wondering what to do, resorting to searching the error online. 8 | 9 | ### Better rockspecs 10 | 11 | Rockspecs aren't *bad*, but they could be better. Here's why. 12 | 13 | #### Format 14 | 15 | Personally, they are painful to write, but this might not be the case for everyone. This has caused me to write projects like [rockwriter][1] or [rockbuild][2]. I would love to see a cleaner format, that is just easier to write. This could still be compiled into static, versioned rockspecs that are serialized Lua tables. But, the user-facing rockspecs should be easier to write. 16 | 17 | #### Versioning 18 | 19 | `luarocks new_version` and versioned files are too rigid. LuaRocks complains if the name isn't exactly right, and `new_version` is just a bunch of configurable fields thrown into a command. I would much prefer some sort of `rock.lua` file whose version can be bumped. 20 | 21 | ### Better interfaces 22 | 23 | Interfacing with LuaRocks can be hard on several fronts: 24 | 25 | #### CLI tool 26 | 27 | The LuaRocks CLI tool does not even let you install more than one package at once, forcing you to type the same command over and over. The list command has unnecessary newlines, everything is plain white... I feel like this could be massively improved to be much more user friendly, nicer to look at... Options to output as JSON/Lua tables could be enabled if we needed to build utility belts. 28 | 29 | #### Webpage 30 | 31 | Ever since the last revision, there are several things that I've changed my mind about here. The current page is fairly good, yet I can't help but side-eye [Hackage][3]. Its main page is not that attractive and could be improved, but the general *feel* of a [package description][4] is something I could go for. 32 | 33 | More stats would also be nice, but not a requirement. 34 | 35 | As for documentation, there will be more on that later. 36 | 37 | ### Dependencies 38 | 39 | LuaRocks has a fair dependency handling, but it isn't powerful enough. While LuaRocks 3 got build dependencies and test dependencies, there is no such thing as optional dependencies, or "install one of"s. The latter can be useful for JSON parsing modules, for example. 40 | 41 | ### Language support 42 | 43 | LuaRocks only works for Lua, and if you use another language that compiles to Lua, you're on your own. You have to compile and provide the files yourself, and it really doesn't make it easy or clean. [Teal][5] struggles to get type declaration files integrated on LuaRocks, and you have to keep all build artifacts for [MoonScript][6]. It doesn't all end here though; there are other languages like Amulet or Fennel that could use LuaRocks support. 44 | 45 | ### Documentation 46 | 47 | Right now, documentation for rocks is kind of a free for all. Most people use [LDoc][7], there are things like [Fir][8], but they are all external and hosted on GitHub Pages or similar. It would be cool to have a centralized documentation repository like [Hackage][9] does with [Haddock][4]. Benefits of this would include being to reference any other rock, consistent styling, and even other features regarding source code analysis which I will go in depth when I release another of my projects. Feel free to contact me about this. 48 | 49 | ### File management 50 | 51 | Right now, LuaRocks forces you to include files in your rockspecs based on Lua modules, and including other files that are not Lua modules or C libraries becomes hard. LuaRocks should just move all specified files over regardless of filetype, because the way it does it right now can be quite confusing. Some files even get renamed in the process. 52 | 53 | [1]: https://github.com/daelvn/rockwriter "daelvn/rockwriter" 54 | [2]: https://github.com/daelvn/rockbuild "daelvn/rockbuild" 55 | [3]: https://hackage.haskell.org "Haskell Hackage" 56 | [4]: https://hackage.haskell.org/package/haddock "Haddock" 57 | [5]: https://github.com/teal-language/tl "Teal" 58 | [6]: https://github.com/leafo/moonscript "MoonScript" 59 | [7]: https://github.com/lunarmodules/LDoc "LDoc" 60 | [8]: https://github.com/daelvn/fir "Fir" 61 | [9]: https://hackage.haskell.org/package/base-4.14.1.0/docs/Control-Monad.html "Control.Monad (base) documentation on Haskell Hackage" -------------------------------------------------------------------------------- /docs/ideas.md: -------------------------------------------------------------------------------- 1 | ## Ideas 2 | 3 | These are the ideas that, on top of fixing LuaRocks' perceived flaws, Meteor should implement. 4 | 5 | ### Windows support 6 | 7 | As much as it pains me, Windows **must** be supported. 8 | 9 | ### Maintainability 10 | 11 | The source code should be accessible, maintainable, open and self-documented to ensure that it's accessible for other collaborators, contributors and maintainers. -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | ## Meteor 2 | 3 | Welcome to the Meteor Package Manager Exploration Project. A package manager exploration project for Lua. Last revised on **January 2021**. 4 | 5 | ### What? 6 | It's too early to call this an alternative package manager for Lua, so I will be calling this a package manager exploration project. The point is looking at what LuaRocks does right, what it does wrong, what could improve and what is completely missing. 7 | 8 | ### Why? 9 | LuaRocks is the choice package manager for Lua, and the one everyone uses for distributing packages. It's not a bad package manager, but it has its flaws. 10 | 11 | ### How? 12 | This repository will mostly contain text for a while. First I would like to collect ideas, input from the community, see what we can do, what we should do, and things like that. 13 | 14 | ### Where? 15 | Check out the concept, ideas and other things here: 16 | 17 | - [LuaRocks flaws](flaws.html) 18 | - [Ideas](ideas.html) --------------------------------------------------------------------------------