search

zesterer / tao

A statically-typed functional language with generics, typeclasses, sum types, pattern-matching, first-class functions, currying, algebraic effects, associated types, good diagnostics, etc.
https://tao.jsbarretto.com/
Mozilla Public License 2.0
1.09k stars 23 forks source link

CI setup #50

Open matthiasbeyer opened 1 year ago

matthiasbeyer commented 1 year ago

Hi,

we talked about this on mastodon. So here it goes.

This is a draft, because it has to be discussed first.

What I do here is more or less the default setup for my repositories. You might not want to have some parts of this setup, I don't know.

Let me explain the individual parts and then we can discuss what you want and what you don't want:

More to come:

Bors setup

The workflow setup is prepared to work with bors as a mergebot. I would strongly recommend setting up bors, as it makes merging and keeping master green so much simpler. But of course that's totally up to you and I can remove the bors specific bits if you want me to!

Feel free to tell me what you think! :laughing:

netlify[bot] commented 1 year ago

Deploy Preview for thriving-beignet-855860 ready!

Name Link
Latest commit cefa40712a166868deff5f914cca05feb2986ac9
Latest deploy log https://app.netlify.com/sites/thriving-beignet-855860/deploys/640c36ae8627570008773c6a
Deploy Preview https://deploy-preview-50--thriving-beignet-855860.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

zesterer commented 1 year ago

For the time being, I'd prefer to just have a basic cargo check CI pass rather than deny warnings + clippy + fmt. While I think those things are useful for a production project, there are many unused things in the codebase that will trigger many warnings (both from rustc and clippy): and that's good! I want to know when something is unused, it's a good reminder for me to implement it. :grinning: Additionally, rustfmt - while nice as a consistent lowest common denominator - tends to wreck havoc with very dense code, actively making it more difficult to reason about. I fear what it would do to the type checker (analysis/src/infer.rs) would be pretty horrid.

matthiasbeyer commented 1 year ago

Ok, I'll remove the bits that you deem unnecessary for now, but in seperate patches so we can easily git-revert them when the time comes.

I will keep the bors compatibility for now, if that's ok.

zesterer commented 1 year ago

Thanks! Much appreciated.

matthiasbeyer commented 1 year ago

So, if you want to set up bors, I can help you with that if you haven't done it before. If not, I can remove the bits that are required for bors.

matthiasbeyer commented 1 year ago

Another thing: As far as I can see, there's no mechanism in the repository to test all that .tao files that are in the repository, is there? I see that there's some testing setup in compiler/tests, but there's a lot more .tao files in the repository than are tested there...

Would you be interested in a test setup that verifies that the existing .tao files work (with or without CI integration)?

zesterer commented 1 year ago

So, if you want to set up bors, I can help you with that if you haven't done it before. If not, I can remove the bits that are required for bors.

I think keeping things simple is fine for now. I really want to emphasise the extent to which this project is just something I'm mucking around with, and it's probably going to take quite a lot of work to push to to a point where people might actually want to use (and depend) on it.

Another thing: As far as I can see, there's no mechanism in the repository to test all that .tao files that are in the repository, is there? I see that there's some testing setup in compiler/tests, but there's a lot more .tao files in the repository than are tested there...

I did make a much earlier attempt at that as you mention, although it was pretty shoddy. I definitely think that having a set of tests specifically for a suite of minimal tests to catch regressions is very useful (and perhaps testing of more official examples too), but everything in test_cases/ is pretty much just me playing around with ideas and IMO shouldn't be expected to compile. I'm sure eventually I'll end up clearing that out and using a .gitignore-d local directory or something instead. As I say, personal project so far so a lot of the repository is a product of that fact.

That said, I want to be careful about over-testing. The language is still in flux and syntax/semantics/core/std change on virtually every commit. I think the worst thing for the project at this stage would be a situation where making a change takes 10 minutes and then fixing all of the tests to account for it takes 30 minutes.

Additionally, features often get removed: for example, the language previously had anonymous sum types (union types) but I removed them because they were muddying the type checker in awkward ways. I want to reimplement them later, but it's this sort of thing that would likely become an enormous maintenance burden without much material benefit if we were to over-test things.