Hacker News Reader

Comment by TamDenholm | Hacker News Reader

Pretty nice idea, be good to see if it gets some traction and becomes popular. I suppose the next step is populating it with the most popular packages and trying to get active adoption with developers.

View on HN

It is in the process of being integrated in the Symfony2 framework, which is one of the largest PHP communities. That should dramatically help adoption.

We have some other plans that will help, but nothing sure. Just talking to various people.

Ultimately though, package management is solving a big pain point. If the user experience is good, and it is easy enough for everyone to use, I would dare say that it can not fail. And don't get me wrong, things are not perfect yet on that front, but we are trying hard, and we welcome any feedback we can get.

Why are you using JSON, exactly? What's the harm in allowing comments in the package description file?

YAML is much better suited IMO, and it has traction.

I really don't think you'd need comments in the package file, but that's not why we picked JSON.

JSON was nice and easy because it's provided natively by PHP, unlike Yaml. Also we were inspired quite a bit by NPM, and I guess that played a role, implicitly.

Also, it is a fact that every format has haters, and we couldn't have picked something that makes everyone happy. So we picked one, and I'm sure people will be able to live with it.

Now I do recognize the fact that some people may not be used to JSON (though I find it quite awkward - even narrow-minded - for web devs), and for that reason I added some syntax checks to warn users of common mistakes in their JSON file, because while PHP has native support, all the info you get from it for malformed JSON is a null return value and "Syntax error" in json_last_error(). We also plan to have an init command that will allow you to build a package file interactively.

> I really don't think you'd need comments in the package file, but that's not why we picked JSON.

What's the harm in letting me decide whether to add comments? Also it's the first place users often look; why not allow me to add useful information? Also, comments have been a big part of programming for decades, and not allowing them without a suitable replacement for annotations is a big step backwards.

> JSON was nice and easy because it's provided natively by PHP, unlike Yaml. Also we were inspired quite a bit by NPM, and I guess that played a role, implicitly.

Yaml can be done in pure PHP so it should not be hard to embed a YAML parser, and I think it would be worth it, to provide something that programmers have taken for granted for decades. Also yes NPM is successful but that doesn't justify copying bad design decisions from it.

> Also, it is a fact that every format has haters, and we couldn't have picked something that makes everyone happy. So we picked one, and I'm sure people will be able to live with it.

This one's easy. Ignore the haters.

> Now I do recognize the fact that some people may not be used to JSON (though I find it quite awkward - even narrow-minded - for web devs), and for that reason I added some syntax checks to warn users of common mistakes in their JSON file, because while PHP has native support, all the info you get from it for malformed JSON is a null return value and "Syntax error" in json_last_error(). We also plan to have an init command that will allow you to build a package file interactively.

With JSON you get experience from it but still trip over it all of the time. Libraries choke on trailing commas, as well they should, because it's a serialization format, not an editing format! Using JSON as an editing format is wrong. Here's a pull request I sent about a trailing comma issue that prevents a repo with 176 watchers from working. https://github.com/atmos/smeagol/pull/15/files

...but you're not creating a new a bad design decision, you're copying a bad design decision, that was copied from somewhere else. And I commend you for coming up with this, as I think the pros outweigh the cons.

"Also it's the first place users often look" — err, no, the package file is for computers, the README for users.

OK, one of the first places users often look. It contains information that's not commonly found in the README, such as dependencies. And I often add comments to dependencies when working with Ruby On Rails, which fortunately uses ruby for its dependency file.

so… for npm, the javascript package manager, using json was a bad design decision?

Yes. Dependency information and script commands are there. Both ought to be able to have comments. Node.js has the ability to load JavaScript, and since it's an installed environment, YAML isn't too much overhead. Both support comments. It can be serialized to JSON if needed.

It can be used more appropriately as a serialization and storage format with npm. It would be a matter of having a script for pushing a package that generates a package.json file from javascript or YAML, and adding it to .gitignore (but not .npmignore) so people see the file with comments enabled.

Given that the parent comment says this is being integrated into Symfony2 (if I read it right), it seems strange to introduce another config format to handle it.

As if a mixture of PHP arrays, YML, annotated comments and XML wasn't quite confusing enough.

Not that I have a problem with JSON itself. It's my serialisation format of choice in PHP as the extra verbosity of its native serialisation seems unnecessary given the lenience of the language.

I actually like having config files as PHP - that way you can not only include comments but hack in logic if you ever have to.

PHP config files are much like PHP templates. It sounds handy to be able to do the odd quick hack in there, but on large scale project it always ends up as a gigantic mess in my experience. Quick hack over quick hack, it slowly turns into an unreadable maze of possibilities.

That being said, for packages I really don't think this applies, because it's static declarative information, I can't imagine why you would need "quick hacks" adding logic to that.

We used to do that with Midgard. Just like embedding in logic into your templates, it gives you a lot of flexibility but ultimately ends up with you or your users shooting yourself into the foot.

For reference, here is one of the old, PHP-based config files we have: http://trac.midgard-project.org/browser/branches/ragnaroek/m...

Using homogeneous architecture has tremendous advantages over using a patchwork of different formats and languages.

Quick example. If you're using native PHP templates and configs, installing APC gives you instant template and config caching with zero effort. To get the same functionality for other formats you would need to roll our your own caching, introducing bugs and complexity along the way, but, most importantly, reinventing the wheel.

That's just one out of myriad examples.

Also, if you have more than two nested levels of arrays (regardless of the language used) in a giant uber-config file, you are the one who is shooting your users into their feet.

Don't code XML in PHP. Refactor. Use includes (which JSON doesn't have, BTW). Use autoconfig pattern and align your configuration file with classes that use them. Use sensible conventions over configuration. Start the file with return statement instead of magic name:

  <?php
   return array(
     'var' => "val",
   );

Nothing will ever scale if you don't even try to design it in a sensible way.

I didn't know that you could return a value from an include like that, that's incredibly handy (and makes me wonder why almost nobody does it that way).

I love this strategy, it's great for config. For example in the RocketSled microframework I mentioned earlier[1] you have a config file to instruct the system which class to execute by default in which you just put:

<?php return 'Hello World';

Being able to include a file like that in your project which returns a value has the advantage (in my opinion anyway) of not cluttering up the namespace with lots of defines(), of not requiring any magic naming convention, and of not having to call out to any external functions or edit config files that are part of the core system's version control.

[1]https://github.com/iaindooley/RocketSled

Admittedly, the example above is quite convoluted. Most of the config files looked like this, which is almost what JSON could look like if it was based on PHP syntax instead of JavaScript:

http://trac.midgard-project.org/browser/branches/ragnaroek/m...

Compared to other formats, it looks like it's missing braces at the top and bottom of the file. YAML gets around it by not requiring trailing commas and not reminding people too much of another format.

Jesus you expected a human to produce that file??? No wonder they shot themselves in the foot! My solution to that wouldn't be a different config format, but less config.

There are advantages and disadvantages. I recently moved to JSON config files for my projects, because they are easy to update from inside the app and because they can be easily validated.

One small, unimportant and low priority suggestion would be to change the layout of the browse page (http://packagist.org/packages/) to a more "app store" type layout. I think something like the ubuntu software center or new chrome web store would really look nice.

Obviously i understand that these codebases dont come with fancy artwork but most have a logo at least that can be used.

Reply on news.ycombinator.com