Greetings.
I just installed Meteor using chocalately so I am a new user. I have some questions to get rolling.
Windows10 machine with a C: drive with Windows (programs) and a D: drive for working storage.
I tried to pass the install path params to install on D: instead of C: under the user/localapp data, that didn’t work. I can accept the installation location, but if there is a way to do this I would like to know.
More importantly I would like to develop projects on the D: drive only. Creating a project there from the tutorial does not generate all the files mentioned (seemed the json-lock file was missing from tutorial), I am also having an issue getting confirmation that the project interacts with meteor :
meteor create D:\simple-todos cd D:\simple-todos meteor
This does not deliver the outcome expected (not successful).
Any help in building projects on a drive other than the meteor install drive is appreciated.
@coagmano
Many thanks for the reply. Point taken, it is more trouble than it is worth.
I will certainly follow suit with windows defender as well as I feel it is “getting in the way”.
Cheers,
WWC
If you are using windows 10, try the windows subsystem for linux and install ubuntu… It is great… I have been using it to develop meteor and other stuff exactly like if I were using linux… If you are used to linux, it is excellent.
I you haven’t heard of it, it is an adapter layer that Microsoft created to run all linux user-space on top of the windows kernal… So, you can actually run the entire ubuntu user space almost unchanged on top of windows. So, basically I am using the linux binaries to run the app not the windows one… it works great… as long as you are not doing something fairly advanced that depends on anything related to the kernal. Most development stacks I used work great.
Meteor is supposed to be supported on Windows. However, there are so many issues with the “Windows” installer, that Meteor on Win is pretty much a non-starter.
The answer here shouldn’t be “Meteor doesn’t work on Windows? Install it in linux instead.”
I use meteor on windows 10 it works well…I appreciate the set up as it is a one time install to get all you need to build an app, you are not concerned with to many details.
There’s issues for sure, but It’s a bit far to say “Meteor doesn’t work on Windows”
Where I work we deploy 90% on Windows 10 machines and half the developers use Windows on their dev machines. Once you get past the first few gotchas it works pretty well
That said, I do rub it in a bit when they have issues, since I never seem to get them haha
I completely agree that Meteor CAN work fine on Windows. However, this is only true if the user is an Administrator, and installs it themselves. Meteor docs make no mention of this.
When scaling up, it is generally a bad idea for all your users to be admins. However, with the current installation approach, that is the only solution.
(Admittedly, you CAN get Meteor running fairly well through some manual moving of files and adjusting PATH, but in this state there will be problems)
@robfallows, have you tried it for a user who does not have Administrative rights? The installer puts everything into the user’s (user who is running the installer) AppData/Local directory (due to several deeper requirements), resulting in ONLY that user being able to access Meteor. If a “normal” user asks an Administrator to do the install, Meteor is only installed for the Administrator account, and that’s just the beginning.
As I understand it, the “normal” user needs to be able to elevate their permissions for the installation phase (that’s what I did, anyway). So, to answer your question: no.
However, that’s basically the same for a Linux or Mac install: the installation requests sudo permissions at the appropriate step. If you don’t have sudo access, you’re in trouble.
I understand that’s not always so easy in a corporate environment, where workstations are locked down.
@robfallows, you are exactly correct on all points you mentioned. Unfortunately, there’s two problems:
“user needs to… elevate their permissions” means "…run as Administrator. If the “normal” user (Joe) does not have Admin rights, someone else with admin rights (IT-Dan) has to enter their credentials. Thus the (installer/cmd/etc…) is now running as the admin user (IT-Dan). The result is that the installer ONLY installs Meteor for IT-Dan.
While some clever manipulation of the directory structure and PATH will get Meteor running for Joe, there are likely to be continually issues with the filesystem and permissions, which would otherwise not be there if Joe had Administrative rights.
Yes - I was agreeing with you. However, I was also pointing out that installation of almost everything in all operating systems requires privilege escalation. I was really wondering what makes Meteor installation any different?
@robfallows, installation of almost everything (including 'NIX, and Windows) only requires admin rights if more than one user needs access to the application. Most installers assume, and only support, system installation. However, almost all such programs (unless they need to run as a separate user, or system access the logged-in user doesn’t have) can be installed for the user only, without Admin rights. The only real differences come down to the installers themselves.
What makes Meteor different?
The installer requires Chocolatey, which while can be installed without admin rights, I’ve ran into other problems using it in such a state to install Meteor.
Manual installation requires admin rights create the symlinks in the meteor package. However, creating these links must also be done manually.
Chocolatey itself only installs into the User’s Local AppData, regardless of permissions.
There are other pain points as well, when trying to run Meteor when installed as/for a user without Admin, or when an Admin has made the required manual adjustments to have it be “installed for all users.”
Ultimately, all of these issues can, and should be solved by the installer itself. It’s fine if the installer requires Admin rights, but it’s not ok for the installer to then put everything in the Admin user’s Local AppData. These are all issues that come down to 'NIX priority support, and windows support being “you can get it working on windows, so that’s good enough.”
I honestly don’t think that’s the attitude. I’m sure it’s more a genuine difficulty in meeting the diverse needs of the community. I know @abernix has pointed out somewhere that the Meteor chocolatey installer is open source, so if you believe it can be improved, I’m sure he’d be delighted to review a PR which improves its adoption in the community.
In my own experience, on Windows Server flavors, once meteor is installed, Administrative Privileges are no longer necessary. This is my experience with a lot of things on Windows, so it doesn’t strike me as terrifying. With the advent of UAC, I (personally) no longer feel like I have to have two separate user accounts (one admin, one normal) to go about my business.
you can get it working on windows, so that’s good enough
I hope that you don’t feel like we do anything with that attitude. It is open-source though, so please help us if you can. Anything we can ever do to reduce the friction is greatly appreciated. The previous installer was much, much harder to maintain (all GUI, required Visual Studio, etc) so the Chocolatey installer is quite a step forward in enabling a better experience.
As to your other points:
Yes, but that page you linked to also immediately states:
NOTE: This option should be a last resort and is considered to be a more advanced scenario - most things you do on Windows require administrative rights, especially surrounding software management, so you are going to be limited even in packages you attempt to install
It’s a Windows limitation that unprivileged users can’t create symlinks. They’ve only recently changed this in Insider builds, but it still requires enabling developer features to do so.
Chocolatey installs to c:\ProgramData\Chocolatey. As stated here.
Honestly, I’m not trying to be difficult here. It’s unfortunately just not simple, we don’t have tons of time to dedicate to it, and we’d appreciate help in improving it.
Ultimately, I think this issue is along the same lines as the difficulty that you’re having? If so, perhaps you could chime in and help? It seems like Chocolatey could maybe do some things different, but to be honest, they’re pretty in-tune with the Windows installation game (it’s literally their business model), so I have to assume they know what they’re doing:
Thank you all. The notes in the “Workaround” are a perfect example of what I was describing, and a perfectly acceptable temporary solution.
I do fully intend on experimenting with the meteor installer to see if I can get it installed for all users, and optionally for the current non-admin user.
So yeah you can get a Node/Meteor dev environment on Windows working but Meteor per se really doesn’t deserve all the blame that the experience is not as delightful as the MacOs / Linux one.
As @abernix mentioned, it’s just not a simple issue.
Wow, this question really struck a nerve. So I put the entire Meteor install on hold, until now.
I have found trying to install Anything that likes to set up C:/ as the ROOT of all really eats up your disk space.
When they ship you a laptop with a 128 GB C:/drive and a 1000 GB D:/drive they should really explain how to manage this situation, C:/ is pretty much reserved for Windows Operating system and a few other key elements.
My Windows work around for all installations (including parts of the User folder that can be huge, Documents, Pictures, Videos, music, source, etc.) is the following:
Go ahead and let the install go on C:/
Go and find the install on C:/ as well as any other folders such as where it will put repos, builds, etc. (could be User)
Rename that folder to “_HOLD” on C:/
Create that path and folder on D:/
CUT the contents of “_HOLD” on C:/ and COPY to the new folder on D:/
** You will need Admin Rights for parts the file copy
cmd prompt as Administrator
Create a Windows Hard link between the Drives and Folders using Junction in cmd window:
Example: mklink /J “C:\Program Files (x86)\Microsoft Visual Studio” “D:\Program Files (x86)\Microsoft Visual Studio”
The folder is recreated as a virtual folder on C:/ and hard linked to whatever folder you pointed to in cmd line
Check that “_HOLD” on C:/ is empty
Delete “_HOLD” on C:/
Go on with life.
It is a pain but this will keep the allocation on C:/ very small and use whatever large drive you have in use.
This is especially useful for parts of the Users folder on C:/ where all docs, videos, music, downloads, and source code usually wind up. NOTE: I say “parts”, you should not try and move the whole Users folder and there will be parts of the folder you can’t rename, so just leave it alone.
I hope this helps a windows 10 user out there somewhere, not only with Metoer install location and projects files, but with all of your installations on a machine set-up to have a “Windows Drive Only”.