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 Mon, 06 Apr 2015 14:28:37 GMT
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 <purplecabbage@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.Barham@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.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
>

---------------------------------------------------------------------
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