Cleaning up syntax

[vasily-kirichenko]

Why we have to quote package names and versions? I mean why we cannot write just

nuget Castle.Windsor ~> 3.3.0

instead of

nuget "Castle.Windsor" "~> 3.3.0"

?

As I understand, neither names nor versions cannot contain whitespaces.

[bartelink]

@vasily-kirichenko This is not a reason why it can never necessarily change, but the actual reason right now is that the impl runs the paket.dependencies as a script to 'parse' it (has slight implications for #94 too - but I definitely wouldn't want to stand in the way of that, which would be fantastic)

[forki]

Actually I removed FCS from paket and wrote a small parser. It's much faster this way. But @agross and I agreed that we would like to keep F# syntax in the dependencies file. This would allow us to use FCS at a later point in time without breaking stuff.

[forki]

So if we could come up with valid F# than it would be awesome.

[agross]

@forki With my vastly enhanced knowledge about F# and function overloads I think we might as well ditch the requirement to have valid F# in paket.dependencies.

I think it might be useful to have a more flexible syntax, e.g. with regard to ~> allowing prerelease updates: nuget "Foo" "~> 1.2" "pre" (or something like that). Or pessimistic version constraint with minimum version required.

In the future, we may have further ideas about such options, with F# (as far as I understand) being somewhat limited in the "optional parameters" space. Please correct me if I'm wrong! :)

[forki]

No you are right.
On Sep 14, 2014 1:07 PM, "Alexander Groß" notifications@github.com wrote:

@forki https://github.com/forki With my vastly enhanced knowledge about
F# and function overloads I think we might as well ditch the requirement to
have valid F# in paket.dependencies.

I think it might be useful to have a more flexible syntax, e.g. with
regard to > allowing prerelease updates: nuget "Foo" "> 1.2" "pre" (or
something like that). Or pessimistic version constraint with minimum
version required
agross@44cf6ac#diff-281c455e627f257e3b4a9a6486ecc687R158
.

In the future, we may have further ideas about such options, with F# (as
far as I understand) being somewhat limited in the "optional parameters"
space. Please correct me if I'm wrong! :)

—
Reply to this email directly or view it on GitHub
#95 (comment).

[ilkerde]

I don't see any concerns against a custom dependencies syntex either. It even gives us more flexibility. +1 here for removing F# constaint for paket.dependencies!

[bartelink]

Oh no, not more flexibility :P

Yes, all makes sense. But it is good to have a story for how one takes various Paket bits and use them in a scripting session...

Maybe that's just

#r "paket.dll"`

let d = paket.Depends """
MyLib >= 3 
"""
paket.Reference """
MyLib
"""

Just thinking out loud - this prob makes no sense!

[ilkerde]

@bartelink I have never thought of how (and if at all) paket info should be used in scripting. I propose this perspective to be a separate issue.

With regards to "flexibility", I only thought of having more options to struture data in deps file, such as prerel info. One even might argue if the redundatnt nuget prefix must be of any requirement then.

Take Pakets own deps file as example:

source "http://nuget.org/api/v2"

nuget
    Newtonsoft.Json ~> 6.0
    UnionArgParser ~> 0.7
    NUnit.Runners ~> 2.6.3
    NUnit ~> 2.6.3
    FAKE ~> 3.4
    FSharp.Formatting ~> 2.4
    DotNetZip ~> 1.9.3
    SourceLink.Fake ~> 0.3 

[vasily-kirichenko]

I agreed that we would like to keep F# syntax in the dependencies file.

Hmm. I cannot understand why it's desirable. If we use custom external DSL, we can (and should) make it as clean as possible, and quotation marks are not clean at all.

[bartelink]

@ilkerde I agree its a separate concern. But changing from internal to external is a fork in the road and whether by accident or design, it was more ready as it is than it would be under an external DSL style. That's all. Perhaps an issue should be spawned; perhaps that shoudl be declared out of scope over some time period

And I was agreeing with you earlier re more flexibility (athough I always cringe when I claim some fantastic increase in generality or flexibility as autromatically meaningful when simplicity and composability are the things that actually really matter...

The other thing ( @vasily-kirichenko this relates to your other proposal too), the source and nuget statements share state/context - the specific source perhaps c/should become part of a single declaration ...

The syntactical capabilities afforded by such a transition also affects (likely in good ways) #96 / #93 and #89

[ilkerde]

@bartelink Thanks for your remarks. With regard to source and nuget statements sharing context: Do you mean we c/should intermingle them? Sth. like

nuget "http://nuget.org/api/v2"
Newtonsoft.Json ~> 6.0
UnionArgParser ~> 0.7
NUnit.Runners ~> 2.6.3
NUnit ~> 2.6.3
FAKE ~> 3.4
FSharp.Formatting ~> 2.4
DotNetZip ~> 1.9.3
SourceLink.Fake ~> 0.3

I'm not sure on how much effort this change would carry out in code. I propose that we first just tackle getting rid of the quotes and nothing more.

[bartelink]

@ilkerde Looks good though now remaining double quotes stick out a bit (and a URL shouldnt have embedded whitespace
And there's no clear unambiguous 'next statement' => indent children (or allow single line), i.e.:

nuget http://nuget.org/api/v2
  Newtonsoft.Json ~> 6.0
  UnionArgParser ~> 0.7
  NUnit.Runners ~> 2.6.3
  NUnit ~> 2.6.3
  FAKE ~> 3.4
  FSharp.Formatting ~> 2.4
  DotNetZip ~> 1.9.3
  SourceLink.Fake ~> 0.3

and

nuget http://nuget.org/api/v2" 
  Newtonsoft.Json ~> 6.0
  UnionArgParser ~> 0.7
  NUnit.Runners ~> 2.6.3
nuget http://nuget.org/api/v2 NUnit ~> 2.6.3
nuget http://nuget.org/api/v2 FAKE ~> 3.4
  FSharp.Formatting ~> 2.4
  DotNetZip ~> 1.9.3
  SourceLink.Fake ~> 0.3

should both be allowed ?

@vasily-kirichenko You're the one that started all this, any opinions on whether both/either are necessary/useful?

[forki]

It's now possible to do

nuget Castle.Windsor ~> 3.3.0

and

nuget "Castle.Windsor" "~> 3.3.0"

at the moment I don't plan to do nesting.

[bartelink]

@forki You considering issuing a deprecation warning re the quotes (and removing support before v1?).

(I think life is hard enough with inconsistent examples posing questions)

[forki]

We will change all docs in v0.2 and break it if needed.
On Sep 17, 2014 12:31 PM, "bartelink" notifications@github.com wrote:

@forki https://github.com/forki You considering issuing a deprecation
warning re the quotes (and removing support before v1?).

(I think life is hard enough with inconsistent examples posing questions)

—
Reply to this email directly or view it on GitHub
#95 (comment).