Comments (1)
Thinking more about requirements and weighing some trade-offs of the original solutions-as-branch plan versus alternatives. Nothing seems to meet the requirements in a nice way.
Requirements
- No duplicated code
- PRs to
master
trigger test of all solutions - Enforceable no-merge policy for PRs with CI failures, even if changes are made to tests/solutions. This means that tests and solutions need to be coupled together in a PR.
Solutions as branch:
- Tracks all solutions-related changes in a separate branch that is easy to compare against
master
. - Incompatible with requirement 3, since a PR to master will omit solutions.
- Best we can do is report whether CI for solutions branch is failing after master is merged, and then make a PR to fix the solutions. Maybe this is good enough.
- CI is more complex with automatic merging across branches.
- Annoying choices to make around branch management strategy, such as whether to go with:
- Merge (or cherry-pick) new content from
master
ontosolutions
.- "Messy", as solutions changes are interleaved with book changes.
- Rebase
solutions
ontomaster
.- "Cleaner", but breaks golden rule of no rebasing public branches.
- May squash all solutions commits to avoid having to perform conflict resolution for multiple commits, but this further tramples on history.
- Merge (or cherry-pick) new content from
Solutions as hidden directory:
Create a .solutions/
directory that matches the structure of exercises/
. This only contains the files that were edited for creating solutions:
.solutions
├── chapter3
│ └── test
│ ├── Main.purs
│ └── Solutions.purs
├── chapter_
│ ├── src
│ │ └── Foo
│ │ └── SomeOtherFile.purs -- exercises require editing this file
│ └── test
│ ├── Main.purs
│ └── Solutions.purs
...
Contents of exercises/
for reference:
exercises
├── chapter3
│ ├── packages.dhall
│ ├── spago.dhall
│ ├── src
│ │ ├── Data
│ │ │ └── AddressBook.purs
│ │ └── Main.purs
│ └── test
│ ├── Main.purs
│ └── Solutions.purs
├── chapter_
│ ├── packages.dhall
│ ├── spago.dhall
│ ├── src
│ │ ├── Foo
│ │ │ └── SomeOtherFile.purs
│ │ └── Main.purs
│ └── test
│ ├── Main.purs
│ └── Solutions.purs
...
Then use rsync
to merge the two directories for testing during CI.
This cuts-down on some file duplication, but there's still lots of duplicated code. There's also no good way to protect against PRs that add new tests, but neglect to update the previously working old tests and solutions tracked in .solutions
.
Solutions as tracked patch file
This is similar to the previous .solutions
directory option, but it tracks all of the solutions changes as a .patch
file to be applied by CI during testing. This is a lot more robust than the directory solution in that it should definitely catch incompatible modifications. It seems perverse to track a patchfile within git, but I believe this meets all requirements.
Difficulties are the following:
- Generating the correct patchfile when updating solutions. Good instructions are required.
- Using the patchfile to view solutions. Maybe it's good for these to be slightly obfuscated. Should provide instructions on how to apply this patch to the reader's local answer-key branch.
- Viewing solutions change history. Will appear as a diff of a diff.
No need to settle on a particular strategy now, and we can pivot from one strategy to another as we learn more about the ergonomics of each.
from purescript-book.
Related Issues (20)
- [Ch3] Indentation docs for `where` are wrong HOT 1
- :memo: Chapter 8 standard form label use HOT 1
- Chapter 11 HOT 1
- chapter 10 duplicated mapSetFoo instead of alternative
- chapter 10 double negation intended or typo? HOT 2
- Chapter 9, final exercise description improvement HOT 1
- Error in Handbook - Asynchronous Effects
- Update Book to PureScript `0.15.0` HOT 2
- Chapter 10: Confusion between `id` and `identity` functions HOT 4
- Getting Started scripts - not all lines are removed
- error ERR_REQUIRE_ESM following instructions in Getting Started HOT 1
- Example from book fails on freebsd HOT 3
- [CH4] A more concise implementation of fibTailRec. HOT 1
- Warning about not using latest spago.
- Swap of Ch4 and Ch5 incomplete HOT 1
- Ch6: Subclass/Superclass confusion for `Ord`/`Eq`
- Not clear that Exercise should include subdirectories
- Can you clarify this no peeking stuff? HOT 3
- Chapter 2, Pythagorean theorem
- Upgrade to the latest package set
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from purescript-book.