package.json format for scripts and binaries

It seems to me you based your package.json on the npm format: https://www.npmjs.org/doc/package.json.html

But by reading the documentation, the 'scripts' member is used for lifecycle management, not binaries. The 'bin' member is for listing executables that should go to the path.

Did you depart from this format on purpose?

Examples:
https://github.com/sstephenson/bats/blob/master/package.json#L7
https://github.com/progrium/gh-release/blob/master/package.json#L7

I'm planning to add this feature to basher, and it would be really sad if basher and bpkg were incompatible.

npm and bpkg are already completely incompatible. npm is for JavaScript, not bash.

On Jul 4, 2014, at 9:24 AM, Juan Ibiapina notifications@github.com wrote:

It seems to me you based your package.json on the npm format: https://www.npmjs.org/doc/package.json.html

But by reading the documentation, the 'scripts' member is used for lifecycle management, not binaries. The 'bin' member is for listing executables that should go to the path.

Did you depart from this format on purpose?

Examples:
https://github.com/sstephenson/bats/blob/master/package.json#L7
https://github.com/progrium/gh-release/blob/master/package.json#L7

I'm planning to add this feature to basher, and it would be really sad if both package managers were incompatible.

—
Reply to this email directly or view it on GitHub.

I edited the comment to make it clear I'm not talking about npm when I say "both package managers". It's about bpkg and basher.

Regardless, my expectation of using 'package.json' is that it at least keeps most of the known and documented logic in place, even though is not compatible with npm itself. If the intent is to diverge from the original, than the choice of the name 'package' and the format 'json' are both misleading and confusing for users.

The format used is similar to component and clibs. Considering a lot of its
users are also owners/contributors it made sense to maintain the same
format. It may be early enough to change the format but a PITA
On Jul 4, 2014 10:01 AM, "Juan Ibiapina" notifications@github.com wrote:

I edited the comment to make it clear I'm not talking about npm when I say
"both package managers". It's about bpkg and basher.

Regardless, my expectation of using 'package.json' is that it at least
keeps most of the known and documented logic in place, even though is not
compatible with npm itself. If the intent is to diverge from the original,
than the choice of the name 'package' and the format 'json' are both
misleading and confusing for users.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Ah, I didn't know what basher is. That makes more sense ;)

I think there was talk of using "bin" for executables already in order to drop the need for an install script.

On Jul 4, 2014, at 10:01 AM, Juan Ibiapina notifications@github.com wrote:

I edited the comment to make it clear I'm not talking about npm when I say "both package managers". It's about bpkg and basher.

Regardless, my expectation of using 'package.json' is that it at least keeps most of the known and documented logic in place, even though is not compatible with npm itself. If the intent is to diverge from the original, than the choice of the name 'package' and the format 'json' are both misleading and confusing for users.

—
Reply to this email directly or view it on GitHub.

@jwerle

@jwerle component uses component.json, which might differ from package.json. I couldn't find any examples of scripts or bin in clibs, although I looked only for a couple of minutes.

@stephenmathieson I like using bins instead of install scripts. That was one of the reasons I revived basher instead of simply using bpkg.

@jwerle

I think bin would be so much easier too.
I'm sorry, I should have noted clibs uses src, not scripts.
I think it is early enough to make changes

On Fri, Jul 4, 2014 at 10:35 AM, Juan Ibiapina notifications@github.com
wrote:

@jwerle https://github.com/jwerle component uses component.json, which
might differ from package.json. I couldn't find any examples of scripts or
bin in clibs, although I looked only for a couple of minutes.

@stephenmathieson https://github.com/stephenmathieson I like using bins
instead of install scripts. That was one of the reasons I revived basher
instead of simply using bpkg.

—
Reply to this email directly or view it on GitHub
#17 (comment).

@jwerle

fwiw, if there wasn't already a small community of people using clib, I'd move from package.json to clib.yml. I've personally run into issues using clib to manage C deps for native node modules. also, json is ugly and hard to read :/

On Jul 4, 2014, at 10:45 AM, Joseph Werle notifications@github.com wrote:

I think bin would be so much easier too.
I'm sorry, I should have noted clibs uses src, not scripts.
I think it is early enough to make changes

On Fri, Jul 4, 2014 at 10:35 AM, Juan Ibiapina notifications@github.com
wrote:

@jwerle https://github.com/jwerle component uses component.json, which
might differ from package.json. I couldn't find any examples of scripts or
bin in clibs, although I looked only for a couple of minutes.

@stephenmathieson https://github.com/stephenmathieson I like using bins
instead of install scripts. That was one of the reasons I revived basher
instead of simply using bpkg.

—
Reply to this email directly or view it on GitHub
#17 (comment).

—
Reply to this email directly or view it on GitHub.

On the same thought, would you think bpkg could use a different format too? For basher I'm considering a package.bash file. I haven't completely decided, but I'll get to it as soon as I have some time.

I love the json parser, and it all looks beautiful, but a native bash format would be both simpler to implement and less confusing. Possible format (making this up on the spot):

NAME="name"
VERSION="1.2.3"
DESCRIPTION="Best package ever"
GLOBAL=true
BIN=bin/exec:otherexec

Let me know what you think.

oh wow - that makes a ton of sense. then we'd just source the package
file, right?

On Fri, Jul 4, 2014 at 12:48 PM, Juan Ibiapina notifications@github.com
wrote:

On the same thought, would you think bpkg could use a different format
too? For basher I'm considering a package.bash file. I haven't completely
decided, but I'll get to it as soon as I have some time.

I love the json parser, and it all looks beautiful, but a native bash
format would be both simpler to implement and less confusing. Possible
format (making this up on the spot):

NAME="name"
VERSION="1.2.3"
DESCRIPTION="Best package ever"
GLOBAL=true
BIN=bin/exec:otherexec

Let me know what you think.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Indeed, but I haven't tested it yet.

Yeah, that looks much better!

On Fri, Jul 4, 2014 at 12:53 PM, Juan Ibiapina notifications@github.com
wrote:

Indeed, but I haven't tested it yet.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Might be a slight security problem though.

http://wiki.bash-hackers.org/howto/conffile

My initial version seems to work well: https://github.com/juanibiapina/basher/blob/master/libexec/basher-install#L25

I'm only using the BIN variable, with a list of binaries separated by ":". Not using NAME or other things for now.

Let me know what you think. If you decide to keep package.json, in whatever format, I might be able to make basher support both package.json and package.sh.

I like the idea of a bash script. How do you feel about an ini file? There is a ini parser written in bash as well here

I think it's simple enough and much safer. The syntax is also very similar to bash.

I don't know how to choose here.

If possible, I would retain as many semantics as possible from npm conventions, and still use a distinct file named bpkg.json, as it explicitly indicates support for bpkg implementations while avoiding the need for per-field conflict resolution. It just seems like unnecessary surface area for issues in the future to attempt to maintain partial compatibility with the evolving npm standards.

@juanibiapina

I have also reversed my opinion and now agree with what @juanibiapina and @ccarpita are saying above. New file (perhaps new format, whatever works for bpkg and basher), but hopefully using the same keywords and names with npm's semantics (simply to leverage well established naming conventions).

@fidian

As (ab)using package.json is already causing problems.

The most vocal contributors in this thread all seem to agree (also) having a bpkg.json is a good idea.

So, moving forward, support for a bpkg.json needs to be added.

Both @fidian and @isaacs suggest an approach I wholeheartedly support:

I'd advocate simply using bpkg.json and falling back to package.json when bpkg.json does not exit. Later on this format can be changed to be an INI file or a shell script or whatnot.

And

I'd suggest a two-fold approach:

If bpkg.json is present, use that.

Else, if package.json is present, use that, but handle scripts/bin/etc. using npm's semantics.

So:

if a project has only a package.json, that is used
if a project has only a bpkg.json, that is used
if a project has both a package.json and a bpkg.json, the bpkg.json is used

Rather than recycling this issue, I'd suggest closing this issue with the common consensus as the conclusion and create a new issue specifically for adding bpkg.json support.

@Potherca

@Potherca I would love to see a PR for this 😉

we've successfully done this for clibs by preferring clib.json and falling back to package.json if it exists! Would love to see it here as well

I'm hoping to give BPKG some love soon, but I can't give any guarantees yet. 🤞

@Potherca

@Potherca I'm going to take a gander at adding support for bpkg.json

@jwerle Would you be to link me, or point me in the right direction, to where this was done for clibs. Although I think I know what the logic would look like, having a reference wouldn't hurt. :)

@SidIcarus

@SidIcarus take a look over here https://github.com/clibs/clib/blob/next/src/clib-install.c and here https://github.com/clibs/clib-package/tree/next

we've finally done it - we moved to bpkg.json

Navigation Menu

Repository navigation

package.json format for scripts and binaries #17

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

package.json format for scripts and binaries #17

Description

Activity

stephenmathieson commented on Jul 4, 2014

juanibiapina commented on Jul 4, 2014

jwerle commented on Jul 4, 2014

stephenmathieson commented on Jul 4, 2014

juanibiapina commented on Jul 4, 2014

jwerle commented on Jul 4, 2014

stephenmathieson commented on Jul 4, 2014

juanibiapina commented on Jul 4, 2014

stephenmathieson commented on Jul 4, 2014

juanibiapina commented on Jul 4, 2014

jwerle commented on Jul 4, 2014

juanibiapina commented on Jul 4, 2014

juanibiapina commented on Jul 5, 2014

jwerle commented on Jul 10, 2014

juanibiapina commented on Jul 10, 2014

23 remaining items

ccarpita commented on Feb 17, 2016

jasonkarns commented on Nov 28, 2018

Potherca commented on Jul 27, 2019

jwerle commented on Jul 27, 2019

jwerle commented on Aug 6, 2019

Potherca commented on Aug 7, 2019

SidIcarus commented on Sep 9, 2019

jwerle commented on Sep 9, 2019

jwerle commented on Mar 25, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions