[V3] Why paket.dependencies should be in repo root?

[alexeyzimarev]

We have the following repo structure:

\
├── src
│   ├── .paket
│   │   ├── paket.bootstrapper.exe
│   │   ├── paket.targets
│   │   ├── paket.exe
│   ├── paket.dependecies
│   ├── paket.lock
├── readme.md
├── build.fsx
├── other files

This worked well in V2. Now with V3 we get build errors that paket.dependencies file is not found and I need to ensure it is in the repo root. Indeed, when I move it there along with paket.lock, the error disappears. But this essentially means I have .paket under the src, however my dependencies and lock files are moved to the repo root despite there is no guarantee there is only one solution in this repo and they will get in conflict.

What was the reason behind the decision to have the dependencies and lock files in the repo root instead of a solution root?

[forki]

tbh it was always meant to look like the following:

\
.paket
│   ├── paket.bootstrapper.exe
│   ├── paket.targets
│   ├── paket.exe
├── paket.dependecies
├── paket.lock    
├── src
├── readme.md
├── build.fsx
├── other files

if v2 allowed the structure that you had then this wasn't really intended. We really believe the dependencies file belong into the root to make things crystal clear. Deps are super important and everyone needs to know about them. This is a major difference to NuGet where it always was intended to hide dependency management.

Sorry if this breaks things for you, but it's really how we think about it.

[cdrnet]

Shouldn't this still work provided you set the working directory to src when running paket.exe? We also have a secondary dependencies file in a subdirectory (which is completely independent with its own packages folder) and do no have any problems with this setup in V3.

[forki]

yes that's correct. but it will only work inside the src folder.

[alexeyzimarev]

I get build errors in Visual Studio, on a solution file that is within the src folder.

Actually I tried to use the structure you suggest but in v2 it just did not work. It required to have .paket folder to be in the same folder as the solution file. Also now I am not sure how this suppose to work since all references to paket.exe and paket.bootstrapper.exe inside csproj files are to ..\.paket\ folder, not to ..\..\.paket

[forki]

Ok. Something is probably messed up now.

Can you please try to convert to the suggested structure and use find/replace in files to fix the path issues? In most case paket install should fix this automatically but it seems something is weird now. If you want you can mail me the solution and I try to fix it for you

[alexeyzimarev]

OK, I run paket auto-restore on and path to both bootstrapper and paket itself seems to be correct. However, <Import Project="..\.paket\paket.targets" /> remains and it fails there although the new (correct) one is added at the end of the project file.

[forki]

I would assume it fix that as well. But seems it doesn't.
Please try to do search / replace and see if it at least stays stable.
On Jun 29, 2016 11:10 AM, "Alexey Zimarev" [email protected] wrote:

OK, I run paket auto-restore on and path to both bootstrapper and paket
itself seems to be correct. However, remains and it fails there. Is it
still needed? Shoudn't V3 remove it automatically?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#1768 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgNCFAFAMXXDNR05ctMtB8rmZY9Zvaks5qQjaSgaJpZM4JA5Pf
.

[alexeyzimarev]

Yes, I changed my comment. auto-restore on fixed the path but it did not touch the path to paket.targets, instead it added a new tag with the right path, keeping the project file failing since the old path prevents it from loading in VS.

[forki]

Ok I guess this is a bug then. Can you please prepare a repro?

[alexeyzimarev]

Here it is https://github.com/alexeyzimarev/Paket.ImportTargets