On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmo...@chromium.org> wrote:
> On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <agri...@chromium.org>
> wrote:
>
> > 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?
> >
>
> I agree at first, but after sleeping on it, perhaps this is not necessarily
> true. Perhaps changing plugin ID could just be a semver breaking change?
> Then, even if it was installed using old plugin-id and the mapper mapped to
> the npm package-name, any plugin compatible with this MAJOR version of the
> plugin would know to use the new plugin id.
>
That'd probably work. In practice I haven't seen plugins pin versions
within <dependency>, but they probably should.
>
> For old versions of the plugin published to npm, we do have to leave the
> plugin id as-is.
>
>
> >
> >
> > Okay, so we don't change the plugin ID, just the package name.
> > - When people use <dependency>, they should still use plugin ID
> >
>
> Nit: why? <dependency> (and config.xml <plugin>) should use the same
> target as "cordova plugin add", which at this point should change to
> package-name. If we do leave plugin-id different from package-name, it
> should only be used internally by plugin authors who depend on other
> plugins.
>
"plugin add" can take git URLs, local directory paths. <dependency id="" />
is pretty clear that it's an ID, and in this form it doesn't specify where
to get the plugin from
The logic for dependency in plugman is to:
1. Fetch it (e.g. use search paths, or find-by-id from the registry).
2. Validate that the plugin.xml we fetched matches the ID from <dependency>
3. Install it
I don't think we can do the validation step if we allow package-name within
<dependency>. Plus, except for core plugins that have a mapper, you
couldn't do the search-path logic correctly without the plugin ID.
>
>
> > - If they "cordova plugin add", we'll allow them to specify NPM package
> > name *or* plugin ID.
> >
>
> Possibly only support plugin-id for some deprecation time? (Though if we
> publish old versions to npm, maybe we just leave it supported + warning
> always)
>
> - 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".
> >
>
> Indeed!
>
>
> >
> >
> > 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:
> >
>
> I tend to agree. I think it *could* work, but we should think through if
> it is necessary.
>
>
> > - 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
