Sorry to be dragging this out, but I think it's important that the plan
here is crystal clear.
On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny <mmo...@chromium.org> wrote:
> I would agree that we should change plugin ID as well as package name, but
> I don't think that affects the results.
>
> All 3 of those use cases you mentioned I think are addressed equivalently.
> Whether the plugin is added as a dependency, with save/restore, or
> explicitly from the command line, cordova-lib would first check if there is
> a mapping from old ID -> new package name, or use what's given verbatim.
> So the only concern is with third party plugin authors who chose to rename
> plugins, and already have dependants, and don't register a mapping with us.
>
There is a runtime dependency on plugin ID. It's used when require()ing
other JS modules, and on Android it's used to access the plugin's native
side (pluginManager.getPlugin("ID")).
We could have a mapper that knows that I type "plugin add "", to fetch
"cordova-plugin-file", but if we also change the plugin ID, then we'll get
runtime problems. So... if we have a mapper, then no changing plugin IDs.
Correct?
Okay, so we don't change the plugin ID, just the package name.
- When people use <dependency>, they should still use plugin ID
- If they "cordova plugin add", we'll allow them to specify NPM package
name *or* plugin ID.
- We'd use the reverse-mapping so that plugin search path will work if they
specify package name.
- E.g. "cordova plugin add cordova-plugin-file", will need to know to
scan search-path directories for "org.apache.cordova.file".
I think the different-IDs-than-package-name approach will work, but I think
it's too much of a hassle to be used by third-party plugins, because it's
more work to have the names be different:
- If their ID is the same as the package name:
- They fit in more naturally with NPM
- The fetching logic will be faster (since we know we don't need to
check CPR first)
- They don't need to send a pull request and wait for a release so that
people can install their plugin (mapper)
If third-parties don't opt into having different package names from plugin
IDs, then down the road the only plugins that will be in this state are the
core plugins. Maybe that's fine?
> I believe the only real question is: do we prefer a minimally easier
> transition by leaving all names as they are, or do we prefer to have
> package names on npm that don't look out of place.
>
> I think any argument that there is a technical preference for one way over
> the other hasn't really held up (but now would be a great time to mention
> if that isn't true).
>
> (Note: choosing leaving names as they are still only guarantees core
> plugins do this, 3rd party authors may not re-publish at all, or rename
> however they want)
>
> -Michal
>
> On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve <agri...@chromium.org>
> wrote:
>
> > Going to try and summarize my concerns with the proposal here:
> >
> > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill <stevengil...@gmail.com>
> > wrote:
> >
> > > Correct! For the first 3 months, all requests will hit CPR first, if
> CPR
> > > fails, we will try to fetch from npm.
> >
> >
> > > If users run "cordova plugin add cordova-plugin-device", it would hit
> > CPR,
> > > fail, go to npm, succeed.
> > >
> >
> > CPR doesn't allow non-reverse dns names. There'd be no reason to check it
> > unless the name had at least 2 periods in it.
> >
> > If we're not using package names to detect which registry to use, I don't
> > actually see any benefit in changing names.
> >
> >
> > >
> > > If we use the mapper module, "cordova plugin add
> > > org.apache.cordova.device" would be converted to cordova-plugin-device,
> > hit
> > > CPR, fail, go to npm, succeed.
> > >
> >
> > While this works fine for our modules, I don't think it'll work well for
> > others'. Three use-cases for them:
> > 1. <dependency> within plugin.xml.
> > 2. <plugin> within config.xml (for cordova plugin restore).
> > 3. cordova plugin add FOO
> >
> > All three would be solved if we enforce that packageName == pluginId.
> >
> > I think we should either:
> > - publish under npm under our existing IDs
> > or:
> > - publish under npm under cordova-plugin-FOO, and change plugin IDs to be
> > cordova-plugin-FOO
> >
> >
> >
> >
> >
> >
> > >
> > > After 3 months, "cordova plugin add cordova-plugin-device" would hit
> npm
> > > first and succeed.
> > >
> > > We want to use these 3 months to get our developers to update their
> tools
> > > and use the new names for plugins to install.
> > >
> > > On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny <mmo...@chromium.org>
> > > wrote:
> > >
> > > > Steve, npm fetch default only affects plugins that use same name in
> > both
> > > > places, right?
> > > >
> > > > If we create cordova-plugin-device today, and tell users to start
> using
> > > > cordova plugin add cordova-plugin-device, then we will get much user
> > > > feedback on npm fetching far before May 18th, right?
> > > >
> > > > On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill <stevengil...@gmail.com
> >
> > > > wrote:
> > > >
> > > > > We don't have one yet but we should pick dates soon.
> > > > >
> > > > > How about:
> > > > >
> > > > > CPR Switch to read only: Monday, May 18th
> > > > > NPM fetch becomes default: Monday, May 18th
> > > > > CPR offline: Monday, August 17th
> > > > >
> > > > > Based on the following proposal:
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
> > > > >
> > > > > - Need to start educating plugin developers to publish to npm as
> > well
> > > as
> > > > > CPR for next three months. (blog post)
> > > > > - Need to educate users to install plugins via new names (if
> > > > package-name
> > > > > is different than id). Our core plugins are being renamed from
> > > > > org.apache.cordova.device to cordova-plugin-device
> > > > > - Inform devs who are working with registry directly to pull
> plugins
> > > from
> > > > > npm instead of CPR. After 3 months, CPR plugins will start to
> become
> > > out
> > > > of
> > > > > date compared to npm versions.
> > > > >
> > > > > Our next plugins release (after the one currently ongoing) will be
> > > > > published to npm as well as cpr.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan <
> > gorkem.er...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > Is there a determined calendar for the npm move of the plugins?
> > > > > > I think the scheduling of the transition is crucial for those who
> > are
> > > > > > using the plugin registry directly.
> > > > > > --
> > > > > > Gorkem
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
