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.er...@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 [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
>
>
