On 31 Mar 2015, at 8:44, Tim Barham wrote:
So... I agree that:
a) if we don't find it in the specified location, we should fail, and
b) storing the version is really superfluous when a source location is
specified (since we're gonna grab whatever is at the specified
location regardless of version).
And particularly since one of our goals with this was to move towards
being more npm'ish - 'npm install' doesn't save the version when you
specify a source location. For example:
"dependencies": {
"semver": "https://github.com/npm/node-semver/tarball/master";
}
Jesse - are you suggesting that rather than having a name and a
?version attribute, we instead store them in a single attribute,
something like the following?
<engine param="windows@^1.2.3" />
<engine param="windows@http://myplatforms/cordova-windows.tgz"; />
(I'm not actually suggesting "param" BTW - just something for the sake
of example)
That's a possibility, though it makes it harder to quickly look up
something by name (that is, simply find the element that has a 'name'
attribute that matches). So I'd prefer to keep the name ad the other
bit in separate attributes, but use the same attribute name whether
we're storing version or source. That, we go with:
<engine name="windows"
xxx="https://github.com/apache/cordova-windows/tarball/master"; />
<engine name="windows" xxx="^1.2.3" />
But where "xxx" is something other than "version" or "src" (something
that works for both types of value). Any suggestions? Only thing that
comes to my mind right now is "at" (because of the "@"):
<engine name="windows"
at="https://github.com/apache/cordova-windows/tarball/master"; />
<engine name="windows" at="^1.2.3" />
Any better ideas?
Ahh.. the stages of config.xml discussions. Starts with "rename things"
continues to "rename more" and usually ends with "let's change to JSON"
:)
It looks like single attribute is preferred, so instead of trying to
find a word that can mean "source and version", we should settle on
version and change it for plugin.
Thanks!
Tim
________________________________________
From: Jesse [purplecabb...@gmail.com]
Sent: Tuesday, March 31, 2015 3:53 PM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
I agree with Andrew, fail loudly if we cannot find it.
And, jam all this into 1 attribute which may or may not have a version
( or
a tag? )
Essentially just store whatever the parameter to 'cordova plugin add'
was.
@purplecabbage
risingj.com
On Mon, Mar 30, 2015 at 5:36 PM, Andrew Grieve <agri...@chromium.org>
wrote:
I don't think we'd want to try a fallback in this case. Better to
fail
loudly if the plugin can't be found where it's expected to be.
I think since NPM uses only a single field (although theirs isn't
labeled),
we should do likewise. Don't feel strongly about it though.
On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales <eymor...@us.ibm.com>
wrote:
It could make sense to store both for the case where restoring from
src
fails. For example, if the path to a local folder no longer exists,
what
do
you use to restore? In that case you could use the version as a
fallback?
Thanks,
Edna Morales
[image: Inactive hide details for "Gorkem Ercan" ---03/30/2015
10:45:03
AM--- On 29 Mar 2015, at 23:11, Tim Barham wrote:]"Gorkem Ercan"
---03/30/2015 10:45:03 AM--- On 29 Mar 2015, at 23:11, Tim Barham
wrote:
From: "Gorkem Ercan" <gorkem.er...@gmail.com>
To: "dev [dev@cordova.apache.org]" <dev@cordova.apache.org>
Date: 03/30/2015 10:45 AM
Subject: Re: Question about plugin/platform --save: src vs version?
------------------------------
On 29 Mar 2015, at 23:11, Tim Barham wrote:
Hi - I'm looking for input on this issue: For the plugin/platform
--save feature, there's currently an inconsistency between how we
store the information in config.xml for platforms vs plugins.
For platforms, we have a 'version' attribute where we store either
the
source location or the version: if the platform was added by
specifying a specific location (git repository, local folder,
package
file etc), we store that in the 'version' attribute. Otherwise we
store the actual version.
For plugins, these two values are stored separately - source
location
in the 'src' attribute and version in the 'version' attribute. Note
however that when we restore a plugin, we ignore the 'version'
attribute if there is a 'src' attribute.
This comes from the history of the implementation ( as these things
do).
In the old experimental save implementation, we had 3 parameters,
namely, version, url and installPath, and for every plugin we
expected
one of them to exist. During the effort for npmizing the save
functionality the contribution for platforms and plugins were done
separately hence the unmatching attributes. So there is no real
technical reason for doing one way or the other and if you are
willing
to unify them that is fantastic.
I'd like to make these consistent. My first thought was to support
'version' and 'src' for platforms like we currently do for plugins.
But since we always ignore the version if we have a src, I'm not
sure
we actually gain anything by doing that. Storing them in different
attributes is perhaps clearer, but storing both implies we make use
of
both, which we don't. Also, the code ends up being simpler overall
if
we just store whichever we care about in the version attribute.
I personally prefer to clearly label data in case user needs to
read/modify the config.xml, seeing a git url on the version
attribute
still puzzles me. But I am fine with either way. Whatever you decide
please remember to support/migrate the current attributes so that we
do
not end up with stale entries on config.xml
Any thoughts either way?
Thanks!
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
