Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Manifest and lock file location #295

Closed
pkieltyka opened this issue Mar 7, 2017 · 5 comments
Closed

Manifest and lock file location #295

pkieltyka opened this issue Mar 7, 2017 · 5 comments

Comments

@pkieltyka
Copy link

Hello,

Im just trying dep for the first time - thanks very much for the work and efforts.

I noticed that dep init produces ./lock.json and ./manifest.json in the project root. Would the committee consider moving those files to ./vendor/lock.json and ./vendor/manifest.json? I believe they are better suited there to stay in their own domain and also keep the file structure much cleaner.

@sdboyer
Copy link
Member

sdboyer commented Mar 7, 2017

Sorry, we're set on them being in the root. #207 and/or #168 have more information.

@sdboyer sdboyer closed this as completed Mar 7, 2017
@pkieltyka
Copy link
Author

@sdboyer ah I see. Thats unfortunate to hear the lack of confidence in keeping vendor/ around.

@sdboyer
Copy link
Member

sdboyer commented Mar 7, 2017

Oh, hopefully that's not too big a worry. I sorta doubt vendor/ will ever actually go away, but I am confident that anything supplanting it will be demonstrably better.

@jusmarks
Copy link

@sdboyer I don't follow. Let's say vendor does go away, wouldn't this tool need to be updated to target the new directory? In other words, if you chose to put the manifest/lock inside vendor, and in the future vendor is deprecated, then this tool would need to be updated to target the new directory. If you chose to put the manifest/lock outside vendor, and in the future vendor is deprecated, then this tool would still need to be updated to target the new directory. How does putting the manifest/lock outside solve the problem?

@sdboyer
Copy link
Member

sdboyer commented Mar 12, 2017

@Justin-Marks yes, if we evolve beyond vendor, then this tool will certainly need to be updated.

The problem is, what happens with all of those already-released versions of code out there in the wild which use the old structure? Do they become invalid, because we moved the location of the files?

Creating incompatibilities with the structures generated by old tool versions entails creating upgrade paths - ones that need to be executed on the fly, without user intervention. That's a huge risk. Moving files around isn't the worst in this class of problem, but there's no sense in inviting Cthulhu if we can avoid it.

If There Is No Now in distributed systems, then Every Time Is Now in package managers.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants