Looks good, do we need to add an assertion that . is actually the correct path (so as to avoid accidentally making this assumption in the future, where these may be sub-paths of the project)?

Looks good, do we need to add an assertion that . is actually the correct path (so as to avoid accidentally making this assumption in the future, where these may be sub-paths of the project)?

If we want to do something like workspaces later, I feel like command_lock will probably need quite a lot of reworking, and I'm not sure there would even be something like a "current project". In a way "current project" is "." by definition?

Looks good, do we need to add an assertion that . is actually the correct path (so as to avoid accidentally making this assumption in the future, where these may be sub-paths of the project)?

If we want to do something like workspaces later, I feel like command_lock will probably need quite a lot of reworking, and I'm not sure there would even be something like a "current project". In a way "current project" is "." by definition?

In my min . is always some form of "working directory". I know @vytautas-astrauskas-sensmetry wants to push towards supporting some type of workspace functionality, where a workspace may contain multiple projects. If something like this happens, I think it not unlikely that lockfiles will exist at a workspace, rather than a project level. In this case . would probably be implicitly interpreted as the directory containing the workspace. In case additional functionality is implemented by someone other than us (or we simply forgot what we wrote here), I suspect this may lead to bugs.

I'd be totally fine with just panic!-ing here though, just to make the failure loud and clear and easy to debug.

EDIT: Specifically, we should panic if . is not the same as the directory sync would look in.

In my min . is always some form of "working directory". I know @vytautas-astrauskas-sensmetry wants to push towards supporting some type of workspace functionality, where a workspace may contain multiple projects. If something like this happens, I think it not unlikely that lockfiles will exist at a workspace, rather than a project level. In this case . would probably be implicitly interpreted as the directory containing the workspace. In case additional functionality is implemented by someone other than us (or we simply forgot what we wrote here), I suspect this may lead to bugs.

I'd be totally fine with just panic!-ing here though, just to make the failure loud and clear and easy to debug.

EDIT: Specifically, we should panic if . is not the same as the directory sync would look in.

I don't really know what check for though. As far as I'm concerned . should always be interpreted as project_root (we may want to rename this if introducing workspaces, and we need to adapt project discovery to be a form of workspace discovery instead). Right now this is where we assume the current project to be. There's no way to assert that this is where the project is because we don't keep track of it any other way.

I don't really know what check for though. As far as I'm concerned . should always be interpreted as project_root (we may want to rename this if introducing workspaces, and we need to adapt project discovery to be a form of workspace discovery instead). Right now this is where we assume the current project to be. There's no way to assert that this is where the project is because we don't keep track of it any other way.

Right, my bad, I thought at least some of this logic happened further down the call stack (a not all inside run_cli).

Could we add an (integration) test case to ensure the correct editable entry and path is set?

Could we add an (integration) test case to ensure the correct editable entry and path is set?

Just found this too #102. I propose we get these two merged quickly and then we prioritise to have a good test suite for lock and sync.

Could we add an (integration) test case to ensure the correct editable entry and path is set?

lock_trivial in cli_lock.rs runs sysand lock on a fresh init and checks that there is a editable with path .. Is there anything more you think would be good to check?

Does this fix #85 or is there something else to do?

Could we add an (integration) test case to ensure the correct editable entry and path is set?

lock_trivial in cli_lock.rs runs sysand lock on a fresh init and checks that there is a editable with path .. Is there anything more you think would be good to check?

Then why did we not catch the bug fixed by this MR?

Then why did we not catch the bug fixed by this MR?

Because it used to check for the absolute path. It's changed as part of this PR.

Then why did we not catch the bug fixed by this MR?

Because it used to check for the absolute path. It's changed as part of this PR.

🤦 I'm either too tired or there is something funky with GitHub's interface, I was sure I checked the list of filenames