You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you switch package servers (by setting the METEOR_PACKAGE_SERVER_URL env var), meteor will create an empty database file in the packages-metadata folder.
However, since it is empty, meteor will give Error: Can't get default release version for track undefined errors for almost anything you try to do.
To solve this, users of stratosphere currently need to copy and rename the existing package db file themselves, and on first connection with stratosphere, they'll receive a database reset command.
It would be great if this step could be left out. The simplest solution would be for meteor-tool to automatically copy and rename the default package server database, but reset the synchronization token to something that would trigger a database reset.
If could create a PR for this if you agree with this approach.
The text was updated successfully, but these errors were encountered:
Currently, supporting this functionality isn't a priority for the project. Perhaps you could just give people a small setup script to run that does what you're suggesting, rather than building it into the tool?
For my open-source meteor package server: https://github.com/sebakerckhof/stratosphere I'm trying to reduce the friction/installation steps for switching package servers.
Currently if you switch package servers (by setting the METEOR_PACKAGE_SERVER_URL env var), meteor will create an empty database file in the packages-metadata folder.
However, since it is empty, meteor will give
Error: Can't get default release version for track undefined
errors for almost anything you try to do.To solve this, users of stratosphere currently need to copy and rename the existing package db file themselves, and on first connection with stratosphere, they'll receive a database reset command.
It would be great if this step could be left out. The simplest solution would be for meteor-tool to automatically copy and rename the default package server database, but reset the synchronization token to something that would trigger a database reset.
If could create a PR for this if you agree with this approach.
The text was updated successfully, but these errors were encountered: