New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alexeyzimarev opened this Issue Jun 29, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

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.

Member

forki commented Jun 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Jun 29, 2016

Member

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.

Member

cdrnet commented Jun 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

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

Member

forki commented Jun 29, 2016

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

@alexeyzimarev

This comment has been minimized.

Show comment
Hide comment
@alexeyzimarev

alexeyzimarev Jun 29, 2016

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

alexeyzimarev commented Jun 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

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

Member

forki commented Jun 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexeyzimarev

alexeyzimarev Jun 29, 2016

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.

alexeyzimarev commented Jun 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

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" notifications@github.com 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
.

Member

forki commented Jun 29, 2016

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" notifications@github.com 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

This comment has been minimized.

Show comment
Hide comment
@alexeyzimarev

alexeyzimarev Jun 29, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

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

Member

forki commented Jun 29, 2016

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

@forki forki closed this in 395baec Jun 29, 2016

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