Skip to content

Improve atomicness#17

Merged
rstacruz merged 2 commits into
masterfrom
improve-atomicness
Jan 29, 2016
Merged

Improve atomicness#17
rstacruz merged 2 commits into
masterfrom
improve-atomicness

Conversation

@rstacruz

Copy link
Copy Markdown
Member

In practice, this allows you to interrupt pnpm install, then run it again, and it'll work just fine after that... no matter where you stopped it.

How?

  • This makes pnpm installs into .store atomic. That is, if it's in .store and .store/lodash@4.0.0/.pnpm_inprogress is not present, you're sure that it's an incomplete installation of a module.
  • With that, this adds .pnpm_inprogress to modules that are currently in progress in being built. It's cleaned up afterwards.
  • node_modules/.tmp is cleaned up afterwards. There's no explicit handling to rm -rf .tmp or anything (that'd be awful!)—simply, if pnpm tries to rebuild a module that has .pnpm_inprogress (ie, from a broken install), it'll know to tear the old .tmp version of that down. Neat.

Why .pnpm_inprogress?

Note that since 0.5.0, pnpm symlinks partial installs from .tmp/0a1b2c3d... into .store/lodash@4.0.0. This allows you to use lodash@4.0.0 while it's being built—sadly something needed by modules that have circular dependencies (ehem, babel-core). Hence, you can't count on the existence of .store/lodash@4.0.0 as a way to determine that lodash@4.0.0 is built.

An empty .pnpm_inprogress file solves that. As long as that file is present, it means it's a transient package that's in the middle of being built.

rstacruz added a commit that referenced this pull request Jan 29, 2016
@rstacruz rstacruz merged commit c36a67f into master Jan 29, 2016
@stefanpenner

Copy link
Copy Markdown

Nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants