cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <leo.treggi...@intel.com>
Subject RE: Question about plugin/platform --save: src vs version?
Date Tue, 31 Mar 2015 20:18:35 GMT
> 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.

If there are multiple pieces of information 'encoded' in a single attribute, then I suggest
that multiple attributes are better.  I'm thinking it's easier to mash multiple pieces of
information back together if necessary, than to split them, making sure all possible 'special
characters' are accounted for.

Being consistent with the plugin saved metadata, as long as the information is equivalent,
would be better.

If you want one name, how about 'origin'.

Leo

-----Original Message-----
From: Jesse [mailto:purplecabbage@gmail.com] 
Sent: Tuesday, March 31, 2015 11:47 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?

Yes, words are hard.

re:
> 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"  />

Yes, but I had only thought of it in a plugin context.

afaik: these are all the ways we can use 'cordova plugin add'

//1. Install by unique name, registry is used to lookup
cordova plugin add plugin-name

//2. Install by unique name, registry is used to lookup, specific version
cordova plugin add plugin-name@version

//3. Install from local folder
cordova plugin add local-path

//4. Install from a repo
cordova plugin add someURI.git

//5. Install from a repo with a specific branch, tag or commit
cordova plugin add someURI.git#r0.2.0

//6. Install from a repo in a specific subdirectory
cordova plugin add someURI.git#:/my/sub/dir

I have no idea what the right terminology would be to encompass all of this.
Presumably also, if we receive an argument as in #1, we should also store
the version number as if we were called like #2











@purplecabbage
risingj.com

On Tue, Mar 31, 2015 at 10:59 AM, Gorkem Ercan <gorkem.ercan@gmail.com>
wrote:

>
>
> 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 [purplecabbage@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 <agrieve@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 <eymorale@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.ercan@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-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>
>>>>
>>>>
>>>>
>>>  ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Mime
View raw message