Meteor Packaging Preview

[Ekaterina Kuznetsova]

Hi everyone!

Today, we are excited to announce the preview release of the Meteor Packaging System. It allows you to publish packages and releases to the meteor packaging preview server (currently located at packages-preview.meteor.com). You can add these packages to apps (that use the new version of meteor), etc. However, keep in mind the following:

This is a preview release, and a preview packaging server. It is intended, specifically, to play around with. As such, we will ERASE ITS DATABASE in about a month, or when we put out the official release. We may also purge it if it turns out that something is terribly wrong with it (we will send mail). Basically, it is a sandbox -- feel free to do whatever you want, but don't expect any permanence. Let us know if you manage to do something super terrible that we don't intend.

For more information on how to use the Meteor Packaging System, check out this awesome doc, by one of our newest employees, Maria Pacana!

https://meteor.hackpad.com/Getting-Started-With-Unipackage-IOckQBQgXaQ

Here is how to run the preview packaging release:

   curl https://install-packaging-preview.meteor.com | sh

You may also wish to put the following in your .bashrc

   alias meteor0=$HOME/.meteor0/meteor

After that, you can use the preview version by running meteor0 (or, if you didn't alias, ~/.meteor0/meteor).  (Unfortunately, making a symlink to this file will not work. This will be irrelevant by 0.9.0.) Running the regular 'meteor' will run whatever you were using before. This is different from how we do pre-releases usually (it is more complicated). That's because we are changing a lot of how we store things on disk. We want to be extra-careful about that. Meteor will go back to being meteor (and not meteor0) when we're closer to a real release candidate.

Do you like the UI of atmospherejs.com? So do we. We look forward to integrating the final package server with it. In the future of 0.9.0, you will be able to use it as well as the command-line 'search' feature. Unfortunately, this is a preview release, so we are not there yet, but 'meteor search' does work! We apologize for the inconvenience.

Some MORE caveats:

  This is a preview release and does not attain to the same standards of output & error reporting as most meteor releases. For example, usually, we work very hard to have good, actionable error messages. Similarly, we try to avoid showing stack traces, or spamming the screen with too much output, etc. We didn't really do that sort of check for this release at all! So, it is a little rough around the edges. Feel free to let me know if something is particularly egregious, but also bear with us.

 

  Startup can be a bit slower than we would like! There are a bunch of calls that we haven't quite gotten around to executing in parallel, for example. We will do some more passes around execution speed before we release a final version. Let us know if it is particularly terrible. 

  Most of the common commands are smart enough to do the right thing. Some of the less common commands might fail to download packages from the server in time, especially if you do something weird. We are looking into it, but, also, feel free let us know if you encounter it.

  There is an exciting new feature, where you can specify an optional architecture argument with bundle. That means that, for example, if you are running on a mac laptop, you can bundle for a linux architecture, including npm modules and stuff, as long as the package has been published from a linux machine as well (with the new publish-for-arch command). Super cool. However! There is a small bug in it, where you may still have to run npm install fibers afterwards (we won't port the dev bundle). We will probably fix this, or document it.

Thanks for being amazing!

-MDG

[Tom Coleman]

Hi Ekate,

Cool stuff!

I’m trying to get a simple package published (the errors package from Discover Meteor — branch here: https://github.com/tmeasday/meteor-errors/tree/unipackage).

I’ve run into a couple of problems:

1. I can’t use `api.versionsFrom('METEO...@0.9.0’)` — if I add that line, my tests fail with the message: "Unknown release”

2. I can’t publish my package — it says:

Error: Cannot find anything about package -- tmeasday:errors

    at ConstraintSolver.PackagesResolver._unibuildsForPackage (packages/constraint-solver/constraint-solver.js:240)

I think I followed the instructions correctly?

Tom

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[Chris Mather]

Congrats Ekate! Very exciting. Can't wait to try it out.

--

[Arunoda Susiripala]

Nice. Can't wait to try that out. 

--

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[David Glasser]

For (1), the release is called 0.9.0-preview2, not 0.9.0 yet.

For (2), we'll look into that soon!

[Morten Henriksen]

Sweet! looking forward to testing it out :)

Btw. I just noted that we finally got add_files in camel case addFiles :) - it may be details but shouldn't we have on_use and on_test converted to onUse and onTest while at it? (it must be some of the last remaining vars not converted to cc yet)

Kind regards Morten

Den fredag den 27. juni 2014 07.45.52 UTC+2 skrev David Glasser:

For (1), the release is called 0.9.0-preview2, not 0.9.0 yet.

For (2), we'll look into that soon!

On Thu, Jun 26, 2014 at 7:02 PM, Tom Coleman <t...@thesnail.org> wrote:
> Hi Ekate,
>
> Cool stuff!
>
> I’m trying to get a simple package published (the errors package from
> Discover Meteor — branch here:
> https://github.com/tmeasday/meteor-errors/tree/unipackage).
>
> I’ve run into a couple of problems:
>

> 1. I can’t use `api.versionsFrom('METEOR-CO...@0.9.0’)` — if I add that line,

[David Glasser]

For (2), there may have been two issues:

(a) Were you in a directory named tmeasday:errors? That was necessary.
(b) There was a bug where it couldn't find your new package from the
on_test. Fixed in 0.9.0-preview3! (meteor0 update FTW)

[Tom Coleman]

It worked! 

On preview4 tests pass, and publishing works. I can see it when I `meteor0 search tmeasday`.  I can add it to an application with `meteor0 add tmeasday:errors`. Exciting times!

PS I can’t see anything at https://packages-preview.meteor.com. Am I supposed to?

PPS I was in a directory called ‘tmeasday:errors’ FYI, so I’m not sure what changed apart from the new version.

[Ekaterina Kuznetsova]

Awesomeness! Exciting to hear! =)

>> PS I can’t see anything at https://packages-preview.meteor.com. Am I supposed to?

Nope, nothing there, client-side. :)

On Saturday, June 28, 2014 2:07:45 AM UTC-7, Tom Coleman wrote:

It worked! 

On preview4 tests pass, and publishing works. I can see it when I `meteor0 search tmeasday`.  I can add it to an application with `meteor0 add tmeasday:errors`. Exciting times!

PS I can’t see anything at https://packages-preview.meteor.com. Am I supposed to?

PPS I was in a directory called ‘tmeasday:errors’ FYI, so I’m not sure what changed apart from the new version.

On Saturday, 28 June 2014 at 7:42 am, David Glasser wrote:

For (2), there may have been two issues:

(a) Were you in a directory named tmeasday:errors? That was necessary.

(b) There was a bug where it couldn't find your new package from the

on_test. Fixed in 0.9.0-preview3! (meteor0 update FTW)

On Thu, Jun 26, 2014 at 10:45 PM, David Glasser <gla...@meteor.com> wrote:

For (1), the release is called 0.9.0-preview2, not 0.9.0 yet.

For (2), we'll look into that soon!

On Thu, Jun 26, 2014 at 7:02 PM, Tom Coleman <t...@thesnail.org> wrote:

Hi Ekate,

Cool stuff!

I’m trying to get a simple package published (the errors package from

Discover Meteor — branch here:

https://github.com/tmeasday/meteor-errors/tree/unipackage).

I’ve run into a couple of problems:

1. I can’t use `api.versionsFrom('METEOR-CO...@0.9.0’)` — if I add that line,

[Ekaterina Kuznetsova]

(Also, thanks for trying it out!)

[Ekaterina Kuznetsova]

[Zoltan Olah]

Nice work everyone, I successfully added tmeasday:errors to my project!

[Arunoda Susiripala]

Hi,

Finally, I got some decent time to play around with the packaging system. I got able to publish kadira as arunoda:kadira. But I encounter couple of issues. And I've some questions.

1. name

package name is picked from the name of the directory. name parameter of the package.js has no meaning. But some of the core meteor packages has name in it. (eg:- mongo-livedata)

I hope this is a temporary behaviour. If not, I really don't like this. I should have full control to place package wherever I need in my machine with a name of my own.

2. mongo-livedata

/Users/arunoda/.meteor0/packages/meteor-tool/.1.0.3.15dresg++browser+os.osx.x86_64/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173

                                                throw(ex);

                                                      ^

[object Object]

So, it seems like there will be sql-livedata, redis-livedata and etc.. :)

3. meta files

There are couple of files generated. They seems like version files.

arunoda:kadira-versions.js

arunoda:kadira:test-versions.js

Do we need to push them to git? does they have effect when I am re-publishing again.

I still haven't play with multi-arch builds. I'll have more questions after that :)

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Phil Cockfield]

This is beautiful work guys!  Regarding the package namespacing by developer account:

<username:packagename>

Is there a concept of "company" as a username, along the lines of Github's orgs?  I'm thinking about packages published by an organization, or a group of folks working together under a shared moniker.  

I guess one way would be to create a new developer account for the organization, and then add a set of 'maintainers' to the package.  Would that be the blessed way, or something would be discouraged within the overarching design of the unipackage system?

Phil

[Phil Cockfield]

Is the test-packages command working in this preview release?

I'm running m0 test-packages phil:test against an app with a structure like this:

app-test (a meteor app)

  |__packages

      |__phil:test (the meteor package with tests)

         |__ test.js 

 

The package.js contains the follow test declaration block:

Package.on_test(function(api) {

  api.use('tiny...@1.0.0');

  api.addFiles('test.js', ['server', 'client']);

});

However when I run m0 test-packages phil:test I get:

While trying to test package `phil:test`:

error: There are no tests for package: phil:test

Is that expected in the current state of the preview?  Or am I doing it wrong.  Thanks!

[Nick Martin]

Thanks Phil!

There is not currently a concept of organizations, but Emily is working on it =). She's currently on a well-deserved vacation, but she can tell you more when she gets back.

We don't want to encourage people to create regular user accounts for organizations -- shared account passwords are so last century =). And we know people want to publish packages as a named group, rather than as an individual username. But we're not going to block 0.9.0 for it if it isn't ready, I think it's more important to get something out there for people to start using.

Cheers,

-- Nick

[Phil Cockfield]

That's great Nick, and the prioritization of that sounds right.  All we need to know is NOT to go doing "dev-accounts as orgs" for now, knowing that there is a "right way" to do this coming down the pike.

Thanks.

[Ekaterina Kuznetsova]

1. name

package name is picked from the name of the directory. name parameter of the package.js has no meaning. But some of the core meteor packages has name in it. (eg:- mongo-livedata)

I hope this is a temporary behaviour. 

The current state of affairs is that your package name is derived from the name of the directory. Unfortunately, I agree that it is not exactly the best. We tried to move away from it with this 'name' field, but ultimately decided that it was slightly too much work to fit it into 0.9.0. So, for now, your directory name must be your package name, and the name parameter of package.js will go away as soon as we clean up the core packages in our repository.

In some future after 0.9.0, we will revisit this idea and try for a better UX around package names. 

2. mongo-livedata

/Users/arunoda/.meteor0/packages/meteor-tool/.1.0.3.15dresg++browser+os.osx.x86_64/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173

                                                throw(ex);

                                                      ^

[object Object]

Ah, [object, Object], my least favorite error. :) If I may ask, how did you get it? We haven't cleaned up everything yet, so it is not terribly unexpected, but I am super curious. :-/

 

3. meta files

There are couple of files generated. They seems like version files.

arunoda:kadira-versions.js

arunoda:kadira:test-versions.js

Do we need to push them to git? does they have effect when I am re-publishing again.

Yes! Thank you for picking up on this, and sorry for not documenting it! :( (I am super excited that you noticed though)

There will be a better explanation in the main hackpad soon. The brief, and not well written explanation is that these are, essentially, the equivalent of the .meteor/versions files, but for the package. For example, if we are building a package for publication, we look at the version files, and use those versions of the packages to build it. Similarly, the multi-arch stuff uses those files to make sure that the same versions of all dependencies are used on the [other architecture] build. 

There is a corner case around building a package in an app, in which case we use the app's version file to determine dependency versions (the idea of building a package locally in your app is to make sure that it has the same context as the app, so it would be bad to have dependency skew). But we still write the versions file for the package, so that if you test your package in an app, and then publish it, the published package will be built with the same versions of dependencies.

 

On Sun, Jun 29, 2014 at 6:54 AM, Zoltan Olah <z...@percolatestudio.com> wrote:

Nice work everyone, I successfully added tmeasday:errors to my project!

On Saturday, June 28, 2014 at 2:07 AM, Tom Coleman wrote:

It worked! 

On preview4 tests pass, and publishing works. I can see it when I `meteor0 search tmeasday`.  I can add it to an application with `meteor0 add tmeasday:errors`. Exciting times!

PS I can’t see anything at https://packages-preview.meteor.com. Am I supposed to?

PPS I was in a directory called ‘tmeasday:errors’ FYI, so I’m not sure what changed apart from the new version.

On Saturday, 28 June 2014 at 7:42 am, David Glasser wrote:

For (2), there may have been two issues:

(a) Were you in a directory named tmeasday:errors? That was necessary.

(b) There was a bug where it couldn't find your new package from the

on_test. Fixed in 0.9.0-preview3! (meteor0 update FTW)

On Thu, Jun 26, 2014 at 10:45 PM, David Glasser <gla...@meteor.com> wrote:

For (1), the release is called 0.9.0-preview2, not 0.9.0 yet.

For (2), we'll look into that soon!

On Thu, Jun 26, 2014 at 7:02 PM, Tom Coleman <t...@thesnail.org> wrote:

Hi Ekate,

Cool stuff!

I’m trying to get a simple package published (the errors package from

Discover Meteor — branch here:

https://github.com/tmeasday/meteor-errors/tree/unipackage).

I’ve run into a couple of problems:

1. I can’t use `api.versionsFrom('METEOR-CO...@0.9.0’)` — if I add that line,

[Arunoda Susiripala]

Hi ekate,

I understand. But I expect name param support will be available before 1.0

Actually, I this is I got that error. 

My package is depend on meteo...@0.9-preview-4

Added mongo-livedata as a direct dependency 

Then try to publish it

I will try releases and forking the cli soon and let you guys know about it. 

[Ekaterina Kuznetsova]

>> Is the test-packages command working in this preview release?

Yes! You have found a bug! (And from out perspective, a somewhat silly one, at that). It should be fixed in preview5. :)

We also changed the version.json filenames in preview5, because we thought about it some more/seemed more elegant to do it differently. Sorry for the annoyance & confusion to all involved.

>> My package is depend on meteo...@0.9-preview-4

>> Added mongo-livedata as a direct dependency 

>> Then try to publish it

Urf. I'll look into this.

- Ekate

1. I can’t use `api.versionsFrom('METEOR-CORE@0.9.0’)` — if I add that line,

To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core+unsubscribe@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[Ekaterina Kuznetsova]

>> I will try releases and forking the cli soon and let you guys know about it. 

Super exciting! =D

[Phil Cockfield]

Awesome!  Thanks Ekaterina

On Monday, June 30, 2014 9:05:25 PM UTC-7, Ekaterina Kuznetsova wrote:

[Abigail Watson]

Hi Ekaterina!
Excited to be trying out the new packaging system!  :)

I gave Meteor 0.9.0-preview5 a try this evening, and ran into a few bumps.  The first unexpected glitch was with api.versionsFrom() which didn't use the syntax that one would expect from --version.  

// expected syntax to use, based on 'meteor0 --version'
api.versionsFrom('Meteor 0.9.0-preview'); 

// what actually worked

api.versionsFrom('METEO...@0.9.0-preview5');

After that, I tried publishing a package 'awatson1978:leaderboard-tinytests-0', and got an ERROR: Match failed [400]

bash-3.2$ meteor0 publish --create 

Building package...

Bundling source...

Creating package...

Creating package version...

ERROR: Match failed [400]

Package could not be published.

I immediately tried publishing again, and got a [403]

bash-3.2$ meteor0 publish --create

Building package...

Bundling source...

Creating package…

Cannot override existing package [403]

 

And when I tried searching for the package, nothing was found (although I could find tmeasday:error).

bash-3.2$ meteor0 search awatson1978

Neither packages nor releases containing the string 'awatson1978' could be found.

Any ideas what Error: Match filed [400] might mean?  And is there any way to delete a package?  I looked through the Hackpad file, and couldn't find any way to --remove or --delete a package.  Any ideas on where to go from here?  Start over with a new package?

Anyhow, thanks for all your hard work!  :)
Abigail

[Isaac Strack]

Abigail,

I was getting the exact same error, and it was tied to the githubURL attribute. I could be a noob, but I don't think the githubURL portion is working just yet / has some error in preview5.

Anyway, remove the githubURL:...   line and it should work for you.

(If anyone knows why exactly that error is getting thrown on that parameter, I'd love to know. need to verify that the GitHub portion is working correctly---thanks!)

-Strack

On Friday, July 11, 2014 11:42:51 PM UTC-6, Abigail Watson wrote:

Hi Ekaterina!
Excited to be trying out the new packaging system!  :)

I gave Meteor 0.9.0-preview5 a try this evening, and ran into a few bumps.  The first unexpected glitch was with api.versionsFrom() which didn't use the syntax that one would expect from --version.  

// expected syntax to use, based on 'meteor0 --version'
api.versionsFrom('Meteor 0.9.0-preview'); 

// what actually worked

api.versionsFrom('METEOR-CORE@0.9.0-preview5');

[Abigail Watson]

Hey, thanks so much Isaac.  
That totally did the trick. githubURL attribute seems to be broken.  

Also, after getting my package published, I tried installing it with 'meteor0 add awatson1978:leaderboard-tinytest-0', and no package directory was created.  Even after running a 'meteor0 update'.  The .meteor/packages directory includes a reference to my package, and the `meteor0 add` command returned without errors.  So, maybe something is the matter with `meteor0 add`?  

But yeah, this is looking great.  I'm excited!  
Abigail

[Morten Henriksen]

Just a note, it seems to have changed name to “git" https://github.com/meteor/meteor/commit/01102d2d4481a7ccc1a2b4d59cfb54165045f589 ?

Venlig hilsen

Morten N. O. Nørgaard Henriksen

Grøn idé ApS - 30 13 12 41

You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/OS54_kc8O5U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

[Chris Mather]

Hi, 

Any plans to merge devel back into preview? I started porting iron-router packages but they depend on the new blaze work in devel. Really looking forward to trying out the new package server and giving feedback!

On that note, there's a bug in resolver.js where it's possible self.unitVersions[candidateName] is undefined.

It seems when trying to api.use('somecorepackage like blaze'), self.unitVersions[candidateName] could be undefined but you're grabbing the 0 index anyway: self.unitVersions[candidateName][0].

Could this be because the package (like "blaze") doesn't exist in core? See screenshot.

. 

[Chris Mather]

BTW In my local fork of Meteor once I merged devel back into packaging-PREVIEW, fixed up some minor conflicts and added version to blaze, blaze-tools and reload-safetbelt everything works great!

[Ekaterina Kuznetsova]

Hey everyone,

First of, my apologies for lack of new preview releases -- we are planning to cut a release candidate for 0.9.0 pretty soon (in about a week), and since this thread seemed to be dead, it seemed more worth it to just wait and fix bugs then. That's why githubUrl doesn't work right now (we changed it to 'git' rather than 'githubUrl' in the final version, and I think I might have accidentally deployed that to the server by accident). That's also why there hasn't been any preview releases merging in devel and some other minor bug fixes. Maybe it makes sense to put out another preview release today or tomorrow that fixes this.

>>  Any plans to merge devel back into preview?

Yup, on our todo list.

>> On that note, there's a bug in resolver.js where it's possible self.unitVersions[candidateName] is undefined.

Thanks so much for reporting this! We might have a variant on our todo list already, but we will make it a priority to fix it.

Thanks so much for porting iron-router, Chris! This is super exciting!

>> Also, after getting my package published, I tried installing it with 'meteor0 add awatson1978:leaderboard-tinytest-0', and no package directory was created.  Even after running a 'meteor0 update'.  The .meteor/packages directory includes a reference to my package, and the `meteor0 add` command returned without errors.  So, maybe something is the matter with `meteor0 add`?  

Much like running 'meteor add [accounts-facebook, for example]', and unlike meteorite, the new meteor packaging system does not create a local package in the packages directory. Instead, the built unipackages are cached elsewhere on disk. For example, this means that if you then have another app, using the same package (& version), you don't need to redownload it.

So, if the app works with the package, that's working as intended, even though the directory doesn't exist! :)

[Abigail Watson]

Huh.  That's going to impact things a bit for people who are in the process of refactoring code into packages, and people who want to make one-off modifications to a package.

Example Use Case #1 - Package One-Off Modifications:  I often create websites with modified sign-in and sign-up pages.  So, instead of using the default accounts-entry-js package, I 'git clone' the accounts-entry package into /packages/accounts-entry, where I can modify the files directly.  If there's a change I want to permanently merge back into the repository, I can do it directly from the /packages directory, and know it will get replicated the same to my other apps.

Example Use Case #2 - Refactoring Packages:  I have a feature I'm trying to refactor out into it's own package.  I start by creating a directory /packages/newpackage, adding a package.js file, and then moving files from /client into /packages/newpackage.  I can build my package inside of an application, and tweak and test it, without having to run two editors.

Is there any workflows in place for these two use cases?  What should we do if we want to clone the contents of a package directly into the app for modification and editing?  Where would those files go?  

Abigail

[David Greenspan]

Ekate can correct me if I'm wrong, but I think there still is a local "packages" directory that works fine.  Meteor just does not put packages there when it downloads them from Atmosphere; it treats them more like core packages in terms of how they are stored and updated.

-- David

[Abigail Watson]

Okidoki.  Good to hear.  I'll try to give that a test this week, then.   Thanks!

[Chris Mather]

Thanks for the update Ekate. In order to make progress converting the iron packages I've created a branch in my Meteor fork, off of packaging-PREVIEW, where I merged in devel in order to get the blaze work. 

I'm hoping that happens on core soon as we're moving forward with porting a bunch of packages (changing their names in the process). If a PR with the merge work would save time or be helpful let me know and I'll send it along!

Can't wait to upload the first set of packages to meteor!

Chris

[David Glasser]

FYI, I merged devel (ie, blaze-refactor) to packaging today.

[Chris Mather]

Sweet!

[Avital Oliver]

Hi Abigail,

On our working branch we made the following change: You can now call `api.versionsFrom("0.9.0")` rather than `api.versionsFrom("METEO...@0.9.0")`. This should make it easier to figure out the argument from the output of `meteor --version`.

Hope this helps!

PS. I genuinely *really* like receiving feedback of any kind. Leave it anonymously at http://www.admonymous.com/avital

[Ekaterina Kuznetsova]

Hi everyone!

Today, we are (once again) excited to announce what is, hopefully, the last 'preview' release of the Meteor Packaging System. Not counting bug fixes reported as part of the release process, we are considering it complete for now: after this we will have release candidates that will the final packaging server. Like all preview releases, this one uses the sandbox preview server for its packages.

IMPORTANT: We have changed some of the recordkeeping in this release, including (minor, but important) changes to the server-side schema.

   - You *must* update to preview-final in order to publish packages to the package server. All previous releases will NOT work.

   - We have wiped the data the preview server. If you have published anything before, you won't find it anymore, it is not there.

   - Please run the following commands to upgrade:

  curl https://install-packaging-preview.meteor.com | sh

Using the normal 'meteor update' mechanisms will NOT work (because we changed a lot of stuff in a backwards incompatible manner. Obviously, future meteor releases will not require you to reinstall the tool). 

We just merged from devel, including all the changes in 0.8.3.

-Ekate

[Andreas Gabriel]

I'm excited, great work!

Although i noticed a bug with the new live reloading of templates. If my application is crashing because of an error in one of my templates the server is not restarting again after fixing the error. I have to kill and start meteor or change something in a js file to get the Server to restart

[David Glasser]

Can you show a reproduction of this?

[Andreas Gabriel]

Just take the boilerplate app created by meteor create ... run it and delete a curly brace of the {{greeting}} helper:

=> App running at: http://localhost:3000/

=> Errors prevented startup:

While building the application:

sampleapp.html:11: Expected `}}`

...ld!</h1>   {{greeting}   <input type="but...

                        ^

=> Your application has errors. Waiting for file change.

Put the brace back in and its not recovering.

[David Glasser]

Thanks, reproduced.

[Morten Henriksen]

Hi Ekate,

I just installed or nealy...

-----------------------

$ curl https://install-packaging-preview.meteor.com | sh

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  2886  100  2886    0     0   1555      0  0:00:01  0:00:01 --:--:--  1555

Downloading Meteor pre-release distribution

######################################################################## 100,0%

cfs-file: updating npm dependencies -- temp...

data-man: updating npm dependencies -- mime, simple-bufferstream, request, temp...

cfs-tempstore: updating npm dependencies -- combined-stream...

cfs-filesystem: updating npm dependencies -- chokidar, mkdirp...

cfs-graphicsmagick: updating npm dependencies -- gm...

cfs-gridfs: updating npm dependencies -- mongodb, gridfs-stream...

/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173

throw(ex);

      ^

Error: Cannot find anything about package -- collectionFS

    at ConstraintSolver.PackagesResolver._unibuildsForPackage (packages/constraint-solver/constraint-solver.js:304)

    at packages/constraint-solver/constraint-solver.js:270

    at Array.forEach (native)

    at Function._.each._.forEach (packages/underscore/underscore.js:105)

    at ConstraintSolver.PackagesResolver._splitDepsToConstraints (packages/constraint-solver/constraint-solver.js:269)

    at ConstraintSolver.PackagesResolver.resolve (packages/constraint-solver/constraint-solver.js:190)

    at _.extend.resolveConstraints (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:312:28)

    at determineBuildTimeDependencies (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/compiler.js:191:26)

    at Object.compiler.getBuildOrderConstraints (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/compiler.js:928:23)

    at _.extend._build (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:609:25)

    at _.extend.getLoadPathForPackage (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:858:14)

    at _.extend.getLoadPathForPackage (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-loader.js:112:29)

    at _.extend.getPackage (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-loader.js:45:25)

    at /Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands.js:171:14

    at Array.forEach (native)

    at Function._.each._.forEach (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)

    at loadPackages (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands.js:167:7)

    at /Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands.js:180:5

    at Object.capture (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:191:5)

    at main.registerCommand.name [as func] (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands.js:175:31)

    at main.longHelp (/Users/raix/.meteor0/packages-from-server/packages-preview/meteor-tool/.1.0.0.yn14vr++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/main.js:1136:23)

Installation failed.

~

$ 

-----------------------

From the collectionFS package.js in local package folder:

Package.describe({

  version: '0.0.0',

  summary: 'Filesystem for Meteor, collectionFS'

});

------------------

So the package is there, in my local dev package folder, I've added version:'0.0.0' - its quite a job had to do this (I got 72 packages at the moment locally more on github)

So I'm just guessing now - but it seems as if only lowercase folders are accepted?

It would be nice if it could be a bit more js/forgiving in terms of breaking installation etc. Maybe it could accept that a package may not have a version if its found locally + find packages ignoring case, maybe just console.warn about naming convention of packages to be lower case.

Well, cant do a quick test on this, and havent got too much time at the moment to dig deeper in this area.

Kind regards Morten

[David Glasser]

Great, should be fixed on packaging now. https://github.com/meteor/meteor/commit/ddc3657e4f4de6a5a20867b95a38c376bda7b9e2