search

PlutoLang / Pluto

A superset of Lua 5.4 with a focus on general-purpose programming.
https://pluto-lang.org
MIT License
367 stars 22 forks source link

Add `flake.nix` #941

Closed cattokomo closed 3 weeks ago

cattokomo commented 3 weeks ago

Related #936

Sainan commented 3 weeks ago

Some concerns:

cattokomo commented 3 weeks ago

You added a lot more junk than just a flake.nix file. I don't see why we need a lockfile, for example. We're not users of this... whatever this is.

If you don't prefer lockfile, we can just pin the commit instead and add flake.lock in .gitignore.

cattokomo commented 3 weeks ago

The flake.nix has a hard-coded version number. We're not going to maintain that. I suggest you do what bundle_deb.php & bundle_nupkg.php do and read the version number from lua.h.

Can't really do that, but we can use CI to bump the version every new release.

Sainan commented 3 weeks ago

I don't get this package manager at all. Why does the flake.nix file have to be in this repository?

Sainan commented 3 weeks ago

Just looking a bit more into this, it seems there is a repository of Nix packages, wouldn't it make more sense to try to get Pluto in here?

alerque commented 3 weeks ago

No. Having it it the nixpgs repo would make sense too, but for totally different reasons than having a Flake — something that has to be in the repository for best effect. I covered this a bit in my last comment. The flake needs to versioned along side the project which enables it to be run at any arbitrary branch, tag, or even commit hash. This can be quite useful for pinning project dependencies and also for regression testing, feature testing, etc.

Sainan commented 3 weeks ago

That seems like a silly way of doing things.

It seems like just checking out (or cherry-picking from) an old git commit and building it from source is still a far more pragmatic approach. And even if Nix were as convenient as you say it is, it doesn't change the fact that Pluto's "core developers" are not on NixOS so I'm not seeing the benefits of this.

If you want an easy way to install Pluto on NixOS or via Nix, I suggest you create and maintain the Nix package on the official user repos.

alerque commented 3 weeks ago

You added a lot more junk than just a flake.nix file. I don't see why we need a lockfile, for example. We're not users of this... whatever this is.

If you don't prefer lockfile, we can just pin the commit instead and add flake.lock in .gitignore.

No, for the flake to be really useful especially for regression testing the lockfile does nede to be tracked.

Everything besides the flack and lockfile can be tidied away in an aux directory though.

alerque commented 3 weeks ago

The flake.nix has a hard-coded version number. We're not going to maintain that. I suggest you do what bundle_deb.php & bundle_nupkg.php do and read the version number from lua.h.

Can't really do that, but we can use CI to bump the version every new release.

Yes you can. There are several ways, but the version should be extracted from wherever it is canonically in the source, not hard coded.

Sainan commented 3 weeks ago

I would certainly be less opposed to this if the version number were not hard-coded into this file, i.e. 0 added maintenance costs for us.

alerque commented 3 weeks ago

That seems like a silly way of doing things.

Just because you don't understand or use it doesn't make it silly.

* We can't exactly add a flake.nix retroactively to the genesis commit.

No of course not. But you can enable it's use for all commits/branches/and versions going forward. Nobody is asking for this in retrospect for old releases.

* The version number is not going to be fully accurate on any non-tagged commit.

Yes it can be. I can come up with examples of projects that do this by deriving the correct version info for each commit, typically with either whatever version is hard coded in the source or in the last release tag plus a counter and git hash info for the current commit.

It seems like just checking out (or cherry-picking from) an old git commit and building it from source is still a far more pragmatic approach. And even if Nix were as convenient as you say it is, it doesn't change the fact that Pluto's "core developers" are not on NixOS so I'm not seeing the benefits of this.

I'm not on NixOS either, but use nix flakes for lots of things. I frequently use them to build projects in CI so that they can be reproduced later without having to build a whole environment from scratch.

It's confusing because there is Nix the OS, Nix the manager, and Nix the language. Poor choice of naming upstream but I'm not in charge. In any case the package manager is lightweight and completely independent of the OS and quite useful for use in stand along projects and CI runners.

If you want an easy way to install Pluto on NixOS or via Nix, I suggest you create and maintain the Nix package on the official user repos.

Again having a package in the official repo is a good thing, but serves a different purpose.

alerque commented 3 weeks ago

I would certainly be less opposed to this if the version number were not hard-coded into this file, i.e. 0 added maintenance costs for us.

Of course that should be fixed, and it should be derived from wherever the canonical version info is stored. It looks like that is hard coded in src/lua.h right now, so it should be derived from that plus a commit counter from whenever that version was tagged, plus a short hash.

Sainan commented 3 weeks ago

I do understand the supposed benefits for developers, but these are the kind of decisions that are meaningless if made by outside folks who don't actually develop on the project.

So, if you are going to ask for "Nix support" or whatever in Pluto, then I will take that as a user asking for a way to install Pluto via Nix. In which case, it seems the official repos are obviously the best way to go about that.

If you, as a user, are asking about having reproducible CI runs, then I can only point at our .deb packages, which can be consumed e.g. via our deb repo: https://github.com/Sainan/warframe-build-evaluator/blob/senpai/.github/workflows/test.yml#L8-L11 (Plus various other ways you could just build it from source if you really wanted to.)