NOT ACTUALLY READY TO MERGE Warn on checkout/dep mismatch
@hyPiRion : this is the basic skeleton of what I think it's going to look like, but I'm curious
- if there's a canonical way to get the filesystem path of a project (see :path-goes-here in my diff)
- what a good automated test strategy for a warning would be
- if you have any other comments.
Thanks for offering your help with this, and sorry for the delay in getting to it.
@j-po: Thanks! I'll have a look at this later today.
Also, running lein bootstrap and bin/lein compile before I started my work changed leiningen-core/pom.xml. Should this go in my PR, or is it a quirk of local development?
Sorry about my rather flexible definition of "later today", I lost this one among some other things I wanted to do. It's next up on my list of things to do, which will hopefully be tomorrow.
You should probably leave leiningen-core/pom.xml out of the commits, but it's not a big deal if you've accidentally slipped it in. It was added to fix #745, but I'm not sure whether this has actually been used lately.
Alright, to the questions you asked:
- You could use
(.getCanonicalFile dep)or(.getCanonicalPath dep)insideread-checkoutsto get the canonical path to the project root, which you can then pass to the warn function - I wish there were any good automated test strategies we could use here, but as far as testing goes, I wouldn't mind just testing the presence and absence of outdated checkouts for a single project. You can probably create a new test project and refer to some existing projects in https://github.com/technomancy/leiningen/tree/master/test_projects (although I guess you'd have to place the test in leiningen, not leiningen-core, then)
- The approach looks good, but do you think you could attempt to limit the lines to around 80 columns? Also, I think the last part of the message
", not the released version."would probably be better read as", not version" project-dep-ver, so that the user knows what's in the project.clj.
Thank you for being patient with me here.