Ok, so... Jesse's ok with 'spec', but prefers 'src'. Gorkem prefers
'version'. Glad we at least agree we need something :).
So, because I'd like to wrap this up and get this change in (in part
because along with this specific change I have a couple of fixes for
platform - save the version that was actually installed, and save it
as a
tilde range), I've coded up all three.
When working on this, one benefit I found with using 'spec' was that
I
think it makes the code clearer. That is, we have this value 'spec'
that
can be a version or a source location, rather than a value 'version'
that
actually might not be a version, or 'src' that actually might be a
version.
I think that has the potential to get confusing quickly. Anyway,
primarily
as a result of that, I created the PR for the change with the 'spec'
attribute [1]. But I also have branches for the 'version' [2] and
'src' [3]
attributes.
Note that for clarity I've renamed variables as appropriate in the
places
where I'm making the immediate change (version --> spec or src, for
example), but to keep the change as simple as possible, I haven't
renamed
various secondary locations that get called by this code (like
lazy_load,
for example).
[1] https://github.com/apache/cordova-lib/pull/202
[2]
https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-version
[3]
https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-src
Thanks,
Tim
________________________________________
From: Jesse <purplecabb...@gmail.com>
Sent: Thursday, April 2, 2015 7:01 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
I'm ok with 'spec'
However; I had always thought we would jam the new single attribute
into 'src' which is much more generic than 'version', and I think is
still close enough in meaning.
I have been looking at this more from the perspective of added
plugins, but I think even the engine tag having a src="^1.2.3" makes
sense. It just means it comes from the 'default' location, at that
particular version.
On Apr 1, 2015, at 6:43 AM, Tim Barham <tim.bar...@microsoft.com>
wrote:
Ahh.. the stages of config.xml discussions. Starts with "rename
things"
continues to "rename more" and usually ends with "let's change to
JSON"
:)
How boring would life be without constantly renaming things to give
the
impression of progress? :)
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.
I could live with that, however I have one final suggestion which
personally I'd much prefer (because I still cringe when I see the
"version"
attribute with a filename or URL as its value)... I won't cry myself
to
sleep if I can't get agreement on it, but I think it is where I'd
cast my
vote... Npm internally uses the term "spec" for this value, and I
think
that works pretty well - it's general enough to cover both scenarios,
while
conveying the right sense:
<engine name="windows" spec="
https://github.com/apache/cordova-windows/tarball/master"; />
<engine name="windows" spec="^1.2.3" />
Tim
________________________________________
From: Gorkem Ercan [gorkem.er...@gmail.com]
Sent: Wednesday, April 01, 2015 3:59 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
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
---------------------------------------------------------------------
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
