Skip to content

Commit

Permalink
Add Workspace planning.md entry
Browse files Browse the repository at this point in the history
  • Loading branch information
cnpryer committed Nov 6, 2023
1 parent bd6d9e2 commit b06c6f2
Showing 1 changed file with 60 additions and 0 deletions.
60 changes: 60 additions & 0 deletions dev-resources/planning.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,66 @@
This document contains structured historical plans for developing Huak.


# Huak Workspaces

## Summary

Workspaces define some scope on a users system. Every workspace has a root. Workspaces are often resolved by searching for a matching file target (more many).

## Motivation

I don't like how coupled workspaces currently are with the rest of the system. This pulls it out and defines it as a kind of common context from which things can occurr. It's up to the rest of the library to figure out how it might be useful.

Check warning on line 12 in dev-resources/planning.md

View workflow job for this annotation

GitHub Actions / Spell check

"occurr" should be "occur".

## Requirements

- Should simplify code
- Should allow for composibility

Check warning on line 17 in dev-resources/planning.md

View workflow job for this annotation

GitHub Actions / Spell check

"composibility" should be "composability".


## Details

Some workspace's data includes:

- root

Huak executes different operations often *from* a workspace. So its useful to define operations that occurr for and against some place on the filesystem.

Check warning on line 26 in dev-resources/planning.md

View workflow job for this annotation

GitHub Actions / Spell check

"occurr" should be "occur".

A workspace can be initialized to a root, or it can be resolved for a path `workspace.resolve_with_target("pyproject.toml")`.


### Composibility

Check warning on line 31 in dev-resources/planning.md

View workflow job for this annotation

GitHub Actions / Spell check

"Composibility" should be "Composability".

Since workspaces are a simple wrapper for some scope on a system you should be able to construct data that allows for nested scopes.

```rust
let workspace = Workspace::new(cwd);
let current_workspace = workspace.resolve_with_target("pyproject.toml")?;
let parent_workspace = workspace.path().parent().map(|it| {
let ws = Workspace::new(it);
ws.resolve_with_target(it)
})

// Create a struct to compose multiple workspaces inside a parent workspace.
struct MyWorkspace {
root: PathBuf,
packages: Vec<Workspace>,
}
```

This is useful for Huak since resolving a workspace can include resolving packages within a workspace. It's on the rest of Huak to make *project experience* good.

### Decoupling

When building the toolchain implementation for Huak it would have been useful to have a common interface for workspace resolution and usage. For example the toolchain can benefit from having an easy way to define a scope for the application. settings.toml will track what scopes in the system have been configured to use a specific toolchain installation.

This would also benefit Huak's development environment experience for projects and virtual environments. The same logic could be used for providing virtual environment mapping for projects.

## Questions

- Should environment data be decoupled from workspaces?
- Should the terminal and other platform concepts also be decoupled?



# Huak's Toolchain

Expand Down

0 comments on commit b06c6f2

Please sign in to comment.