cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Barham <Tim.Bar...@microsoft.com>
Subject RE: Question about plugin/platform --save: src vs version?
Date Wed, 01 Apr 2015 13:43:07 GMT
> 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.ercan@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 [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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message