Hi, Steve: Yes, that makes sense. I guess I was thinking that if git could see the changes, you could still commit from the VM, even if you had to know to do that.
I have to use v: not because of the path, but because of the symlink at c:/vagrant, which npm and other packages can't work with. With npm you have an option to work around this by setting bin-links to false, although there are side effects. Even with bin-link set to false, my tests typically do not run, which is why I use the other approach. Anyway, I chimed in because I was fishing for a better alternative to my current solution, and very much interested in decoupling node_modules between the host/client. It sounds like we each need something different, and I'll have to keep fishing. Cheers, Tony On Thu, Jun 8, 2017 at 4:27 PM, Steve Grundell < [email protected]> wrote: > Hi Tony, > > If you where to add something to c:\gpii, it would not be on the host. > This is a effectively cheap alternative to rsync where you're just linking > the containing directories, rather than copying. For what use it for > (update-run/debug-repeat), it's not an issue and for sanity I still run > tests in \vagrant (actually, I have a clean VM for them). I don't do any > work in the VM. > > If you where wondering about git status on the VM, it recognises that the > files/directories have been replaced with symlinks - which is unwanted but > correct. > > The lock file might work - but only by accident. It turns out that you can > "npm install" in a directory containing only a link to > \\vboxsvr\vagrant\package.json (no other files), because npm resolves the > link and uses the target as the base to load relative paths (node_modules > is created relative to the working directory, keeping it in the vm speeds > things up and allows symlinks). > > This means, in theory, the lock file on the host will be used even though > it doesn't appear in c:\gpii. Confusing, but working. Interestingly (to me > at least), GPII can start by just having a symlink to gpii.js. > > The same phenomenon applies also when using c:\vagrant (you see Infusion > loaded from \\vboxsvr). I bet this is why you need to map the drive, > because something you're using doesn't like a "\\" path. > > Steve > > > > On Thu, Jun 8, 2017 at 10:04 AM, Tony Atkins <[email protected]> > wrote: > >> Hi, Steve: >> >> I've also encountered problems with symlinks when running under >> c:\vagrant, and for the same reasons. As we've discussed on IRC and in >> other meetings, I worked around these by mounting the share as a named >> drive (I use V: for "Vagrant"). This has worked very well at least in my >> experience, as long as I remember to clean out node_modules in the host >> environment or use rimraf within the VM. >> >> I do like that your approach helps with the node_modules problem, but I >> wonder about new material. By that I mean, if a command or tests generate >> reports or other output, with the "shared drive" approach, you end up >> having access to the reports from the host VM, being able to check for lock >> file staleness (see previous email). If you symlink the .git directory as >> well, what does "git status" show if you create a file in c:\gpii? >> >> Cheers, >> >> Tony >> >> On Wed, Jun 7, 2017 at 4:20 PM, Steve Grundell < >> [email protected]> wrote: >> >>> Hi >>> >>> I think I've done something of interest to others. It's a bit of a hack, >>> but I've been able to (from within the Windows VM) use npm link and keep >>> the node_modules inside the VM. >>> >>> All I wanted to do is put links inside node_modules (links that actually >>> look like links to Windows, and not have npm complain about >>> node_modules/universal being a clone), and mklink doesn't work on any >>> network fs I've tried. >>> >>> Here;s the thing: >>> - Make the vagrant shared directory read-only (optional, but it feels >>> good). >>> - Create a directory in the VM: c:\gpii >>> - Create a link to each file/directory in the source root except for >>> node_modules. (in the VM I run links.bat[1] then rmdir node_modules) >>> - npm install, and node_modules is created in c:\gpii on the VM drive, >>> and everything else is loaded from the host (by following the symlinks). >>> >>> So, it's similar to how c:\vagrant links to "everything" - but it links >>> to "almost everything". >>> >>> This feels it should work, however when you decide to run gpii.js (which >>> is a symlink) it resolves to "\\vboxsvr\vagrant\gpii.js" and then >>> everything else becomes relative to that (including node_modules). >>> >>> Fortunately, this resolving is just performed by >>> fs.realpath/realpathSync so after a quick hack to force everything in >>> "\\vboxsvr\vagrant\" to really resolve to "c:\gpii\" (adjust-links.js[2]), >>> node now loads things from c:\gpii leaving the OS to resolve it. You just >>> have to add a --require option to node: >>> >>> gpii-windows: node --require adjust-links.js gpii.js >>> gpii-app: node_modules\electron\dist\electron.exe --require >>> c:\gpii\adjust-links.js main.js >>> >>> I've been using this for a few weeks - forgot all about it until now (I >>> "re-provision" using snapshots). >>> >>> Steve >>> >>> [1] links.bat: https://gist.github.com/stegru >>> /ea0e1190bca2e02ec9255348a01232a2 >>> [2] adjust-links.js: https://gist.github.com/stegru >>> /ec8eb3f9637e6f4d8c0619e8d0c54293 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> http://lists.gpii.net/mailman/listinfo/architecture >>> >>> >> >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
