Optional lockfile?

[dieggsy]

I know simplicity is the name of the game here, but would you consider support for an optional lock file?

Could be something like:

# write out lockfile
vend freeze > lockefile.lisp
# read from lockfile
vend get -l lockfile.lisp

Personally I like the idea of reproducible dependencies that are not committed to the source tree.

[fosskers]

Thanks for the suggestion, I will think about this.

[dieggsy]

Maybe lock would be a better verb or subcommand name

[fosskers]

Yes, and I'd probably just write it not as lisp but a plain text file.

[dieggsy]

That would work. I just figured something like

("system" . "<ref-or-commit>")
...

would be dead simple to read/write, but it's certainly not like parsing a simple text file is really much more work.

[VisenDev]

Having a lockfile would kind of be the same thing as a custom registry as referenced here right? #16

It would just the a custom registry that is automatically generated by vend via the proposed vend freeze command

[VisenDev]

Yes, and I'd probably just write it not as lisp but a plain text file.

What do you mean by a plain text file? You mean just having a whitespace separated list or a csv? Why would that be better than storing data in S-Expressions?

[fosskers]

The problem with a lockfile is that it would create a second source of truth. Say I pull via vend get, which respects the lockfile, then I go into vendored/ anyway and change the commits around?

Things stay simple if it's just vendored/.

[dieggsy]

IMO at that point it becomes the vend user's responsibility to either re-do the lockfile from the current state, or reset the repos to the lock file state if the changes were temporary (I guess vend get could do this relatively straightforwardly, but eh)

[fosskers]

I'll keep thinking.