You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Carlos Santana <cs...@gmail.com> on 2020/03/01 17:26:59 UTC
Re: wskdebug: npm module name?
My two cents:
Publishing to npm would be a community thing as a convenience not an official distribution guaranteeing the bytes for a third party service (ie npmjs.org)
No need to vote on the npmjs.org published, vote should already happened for the source code and the tgz source code published.
Just setup some scripting that publishes the already voted tgz source to npmjs.org server.
- Carlos Santana
@csantanapr
> On Feb 28, 2020, at 11:43 AM, David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> Alexander Klimetschek <ak...@adobe.com.INVALID> wrote on 02/28/2020
> 01:44:51 AM:
>>
>>> We own both the @openwhisk and @apache-openwhisk organizations, so
>>> we could choose to use either as a scope for this new package.
>>
>> I did not see any @openwhisk or @apache-openwhisk scopes on npm (no
>> results for e.g. [1]). Which are you referring to?
>
> We have not published a package to either one of these scopes, but the
> organizations already exist and are owned by the PMC's "openwhisk-bot"
> functional id. The existence of the org claims the scope.
>
> We should be able to publish a package to either one of those scopes at any
> time without additional setup (after we go through the usual voting process
> to actually have content to put there).
>
> --dave
Re: wskdebug: npm module name?
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
> The few files without licenses are types we generally exclude as not needing them (*.json, pom.xml).
rcverify was complaining about them and I saw no exclusion mechanism?
Cheers,
Alex
________________________________
From: David P Grove <gr...@us.ibm.com>
Sent: Tuesday, March 3, 2020 11:28
To: OpenWhisk Dev <de...@openwhisk.apache.org>
Subject: RE: wskdebug: npm module name?
Alexander Klimetschek <ak...@adobe.com> wrote on 03/03/2020 12:17:47 AM:
>
> Thanks. Here are the PRs:
> https://github.com/apache/openwhisk-wskdebug/pull/2
> rcverify.sh: https://github.com/apache/openwhisk-release/pull/330
> with this rcverify.sh should pass for a new release in
openwhisk-wskdebug.
>
Thanks Alex. rcverify is happy now. I also checked with Apache RAT and
things look good. The few files without licenses are types we generally
exclude as not needing them (*.json, pom.xml).
When you are happy with the state of the code, please kick off a DISCUSS
thread proposing a release.
--dave
RE: wskdebug: npm module name?
Posted by David P Grove <gr...@us.ibm.com>.
Alexander Klimetschek <ak...@adobe.com> wrote on 03/03/2020 12:17:47 AM:
>
> Thanks. Here are the PRs:
> https://github.com/apache/openwhisk-wskdebug/pull/2
> rcverify.sh: https://github.com/apache/openwhisk-release/pull/330
> with this rcverify.sh should pass for a new release in
openwhisk-wskdebug.
>
Thanks Alex. rcverify is happy now. I also checked with Apache RAT and
things look good. The few files without licenses are types we generally
exclude as not needing them (*.json, pom.xml).
When you are happy with the state of the code, please kick off a DISCUSS
thread proposing a release.
--dave
Re: wskdebug: npm module name?
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
Thanks. Here are the PRs:
* https://github.com/apache/openwhisk-wskdebug/pull/2
* rcverify.sh: https://github.com/apache/openwhisk-release/pull/330
with this rcverify.sh should pass for a new release in openwhisk-wskdebug.
Cheers,
Alex
________________________________
From: Rodric Rabbah <ro...@gmail.com>
Sent: Monday, March 2, 2020 18:42
To: dev@openwhisk.apache.org <de...@openwhisk.apache.org>
Cc: David P Grove <gr...@us.ibm.com>
Subject: Re: wskdebug: npm module name?
We don’t have a mechanism to white list files per repo so you’d have to make a change in the rcverify itself.
(We exempt bash scripts for example this way.)
-r
> On Mar 2, 2020, at 9:40 PM, Alexander Klimetschek <ak...@adobe.com.invalid> wrote:
>
> There are some license and formatting issues that will need to be fixed
> before we can make a release. I don't think there is anything deep, but
> we'll need some fixups to get a clean run from our 'rcverify.sh` tool [1]
> I am working on making it pass as part of my PR.
>
> Question: The "executable files" check does complain about one executable file - "cli.js". However this has to be executable in the sources, as this is the entry point for wskdebug as a node/npm cli. It is set as the bin file in npm [2] [3]. You also want this in the git sources to make local development via npm link work, so delaying setting of the exec flag on npm publish would not be a solution. (No linking in Javascript/Nodejs :-))
>
> Can there be an exclusion list? Change rcverify.sh directly?
>
> [1]
> https://github.com/apache/openwhisk-release/blob/master/tools/rcverify.sh
> [2] https://github.com/apache/openwhisk-wskdebug/blob/master/package.json#L18-L19
> [3] https://docs.npmjs.com/files/package.json#bin
>
> Cheers,
> Alex
>
>
Re: wskdebug: npm module name?
Posted by Rodric Rabbah <ro...@gmail.com>.
We don’t have a mechanism to white list files per repo so you’d have to make a change in the rcverify itself.
(We exempt bash scripts for example this way.)
-r
> On Mar 2, 2020, at 9:40 PM, Alexander Klimetschek <ak...@adobe.com.invalid> wrote:
>
> There are some license and formatting issues that will need to be fixed
> before we can make a release. I don't think there is anything deep, but
> we'll need some fixups to get a clean run from our 'rcverify.sh` tool [1]
> I am working on making it pass as part of my PR.
>
> Question: The "executable files" check does complain about one executable file - "cli.js". However this has to be executable in the sources, as this is the entry point for wskdebug as a node/npm cli. It is set as the bin file in npm [2] [3]. You also want this in the git sources to make local development via npm link work, so delaying setting of the exec flag on npm publish would not be a solution. (No linking in Javascript/Nodejs :-))
>
> Can there be an exclusion list? Change rcverify.sh directly?
>
> [1]
> https://github.com/apache/openwhisk-release/blob/master/tools/rcverify.sh
> [2] https://github.com/apache/openwhisk-wskdebug/blob/master/package.json#L18-L19
> [3] https://docs.npmjs.com/files/package.json#bin
>
> Cheers,
> Alex
>
>
Re: wskdebug: npm module name?
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
There are some license and formatting issues that will need to be fixed
before we can make a release. I don't think there is anything deep, but
we'll need some fixups to get a clean run from our 'rcverify.sh` tool [1]
I am working on making it pass as part of my PR.
Question: The "executable files" check does complain about one executable file - "cli.js". However this has to be executable in the sources, as this is the entry point for wskdebug as a node/npm cli. It is set as the bin file in npm [2] [3]. You also want this in the git sources to make local development via npm link work, so delaying setting of the exec flag on npm publish would not be a solution. (No linking in Javascript/Nodejs :-))
Can there be an exclusion list? Change rcverify.sh directly?
[1]
https://github.com/apache/openwhisk-release/blob/master/tools/rcverify.sh
[2] https://github.com/apache/openwhisk-wskdebug/blob/master/package.json#L18-L19
[3] https://docs.npmjs.com/files/package.json#bin
Cheers,
Alex
RE: wskdebug: npm module name?
Posted by David P Grove <gr...@us.ibm.com>.
Alexander Klimetschek <ak...@adobe.com.INVALID> wrote on 03/02/2020
06:17:42 PM:
>
> @openwhisk/wskdebug
>
> I will create a PR.
sounds good.
>
> And then ask for an initial release (keeping the version number to
> avoid confusion), plus vote.
There are some license and formatting issues that will need to be fixed
before we can make a release. I don't think there is anything deep, but
we'll need some fixups to get a clean run from our 'rcverify.sh` tool [1]
--dave
[1]
https://github.com/apache/openwhisk-release/blob/master/tools/rcverify.sh
Re: wskdebug: npm module name?
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
Thanks for the responses! It seems folks agree on
a) openwhisk to be in the name and
b) leverage one of the existing npm scopes @openwhisk or @apache-openwhisk
Based on that I would propose to go with suggestion 3:
@openwhisk/wskdebug
I will create a PR.
And then ask for an initial release (keeping the version number to avoid confusion), plus vote.
Agree with Carlos, this must follow ASF release process and then push to npm is just one convenience "mirror" from the ASF perspective. I have seen this practiced well with https://github.com/apache/openwhisk-client-js
(Although not for your normal npm developer, they will be _very_ confused if something is not on npmjs.org :-) Just saying.)
Thanks,
Alex
________________________________
From: Carlos Santana <cs...@gmail.com>
Sent: Sunday, March 1, 2020 09:26
To: dev@openwhisk.apache.org <de...@openwhisk.apache.org>
Subject: Re: wskdebug: npm module name?
My two cents:
Publishing to npm would be a community thing as a convenience not an official distribution guaranteeing the bytes for a third party service (ie npmjs.org)
No need to vote on the npmjs.org published, vote should already happened for the source code and the tgz source code published.
Just setup some scripting that publishes the already voted tgz source to npmjs.org server.
- Carlos Santana
@csantanapr
> On Feb 28, 2020, at 11:43 AM, David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> Alexander Klimetschek <ak...@adobe.com.INVALID> wrote on 02/28/2020
> 01:44:51 AM:
>>
>>> We own both the @openwhisk and @apache-openwhisk organizations, so
>>> we could choose to use either as a scope for this new package.
>>
>> I did not see any @openwhisk or @apache-openwhisk scopes on npm (no
>> results for e.g. [1]). Which are you referring to?
>
> We have not published a package to either one of these scopes, but the
> organizations already exist and are owned by the PMC's "openwhisk-bot"
> functional id. The existence of the org claims the scope.
>
> We should be able to publish a package to either one of those scopes at any
> time without additional setup (after we go through the usual voting process
> to actually have content to put there).
>
> --dave