Use file instead of dir locking #187 #203
Conversation
This commit simply imports the code from the filelock package verbatim into a subdirectory, filelock. Depending on filelock as an external package instead would be more straightforward, but I'm not sure what the rules for external dependencies are here.
|
Looks like this would address #126 as well. |
|
...if we wanted to use the |
|
Unless you edited a comment to say something different than it did originally, I haven't seen any comment stating that filelock was considered and excluded, much less a reason given for this decision. I'd appreciate if you could point to where this comment was made. |
Given that the extra dependency doesn't seem to be a problem, remove the inlined code. If in fact the dependency should be avoided, just ignore this commit and use the parent.
NOTE: This is included via an extra-dep, which would constitute the first time Stack would include a patched version of an upstream library. This is due to the fact that haskell/hackage-security#203 is likely not going to be merged, despite fixing issues affecting Stack. This leaves us with (AFAICT) 4 choices at the Stack level: 1. Continue using the officially released upstream version of hackage-security, bugs and all 2. Fork hackage-security on Hackage, and depend on the fork 3. Inline the code from hackage-security into Stack itself, and drop the explicit dependency on hackage-security 4. Include hackage-security via an `extra-dep` pointing at a Git commit. Our official builds will use the patched version of hackage-security, and anyone building from Hackage will end up with the unpatched version This PR represents approach (4). If and when the PR is merged and released to Hackage, this becomes a non-issue. But generally speaking, we should have a policy in Stack for handling these kinds of upstream issues cases.
|
Even if a better solution is coming, can't we merge this PR for now as a stopgap and then drop the |
|
@hvr I didn't see what the problems with filelock are? Can you point it out? On the face of it I'm inclined to agree that we take the patch and use filelock, and we can of course still make further changes and improvements later. |
|
Fair enough, let's merge this as a a temporary stopgap solution for now. |
|
Ok, so the issue is the unix
|
NOTE: This is included via an extra-dep, which would constitute the first time Stack would include a patched version of an upstream library. This is due to the fact that haskell/hackage-security#203 is likely not going to be merged, despite fixing issues affecting Stack. This leaves us with (AFAICT) 4 choices at the Stack level: 1. Continue using the officially released upstream version of hackage-security, bugs and all 2. Fork hackage-security on Hackage, and depend on the fork 3. Inline the code from hackage-security into Stack itself, and drop the explicit dependency on hackage-security 4. Include hackage-security via an `extra-dep` pointing at a Git commit. Our official builds will use the patched version of hackage-security, and anyone building from Hackage will end up with the unpatched version This PR represents approach (4). If and when the PR is merged and released to Hackage, this becomes a non-issue. But generally speaking, we should have a policy in Stack for handling these kinds of upstream issues cases.
|
@snoyberg thanks for poking through the issues that this resolves. |
This reverts commit d91afd3.
NOTE: This is included via an extra-dep, which would constitute the first time Stack would include a patched version of an upstream library. This is due to the fact that haskell/hackage-security#203 is likely not going to be merged, despite fixing issues affecting Stack. This leaves us with (AFAICT) 4 choices at the Stack level: 1. Continue using the officially released upstream version of hackage-security, bugs and all 2. Fork hackage-security on Hackage, and depend on the fork 3. Inline the code from hackage-security into Stack itself, and drop the explicit dependency on hackage-security 4. Include hackage-security via an `extra-dep` pointing at a Git commit. Our official builds will use the patched version of hackage-security, and anyone building from Hackage will end up with the unpatched version This PR represents approach (4). If and when the PR is merged and released to Hackage, this becomes a non-issue. But generally speaking, we should have a policy in Stack for handling these kinds of upstream issues cases.
|
No problem @dcoutts :) |
This commit simply imports the code from the filelock package verbatim into a subdirectory, filelock. Depending on filelock as an external package instead would be more straightforward, but I'm not sure what the rules for external dependencies are here.