Repository navigation
Cleaning up syntax #95
Description
Activity
@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.dependenciesas 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)So if we could come up with valid F# than it would be awesome.
@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! :)
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
https://github.com/agross/Paket/commit/44cf6ac0357d62e955a8edac0d75012f86dfa0f0#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).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!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!
@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
depsfile, such as prerel info. One even might argue if the redundatntnugetprefix 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.3I 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.
@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
sourceand 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
@bartelink Thanks for your remarks. With regard to
sourceandnugetstatements sharing context: Do you mean we c/should intermingle them? Sth. likenuget "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.3I'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.
@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.3and
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.3should both be allowed ?
@vasily-kirichenko You're the one that started all this, any opinions on whether both/either are necessary/useful?
- added a commit that references this issue
on Sep 17, 2014 It's now possible to do
nuget Castle.Windsor ~> 3.3.0and
nuget "Castle.Windsor" "~> 3.3.0"at the moment I don't plan to do nesting.
- added a commit that references this issue
on Sep 17, 2014 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).- added a commit that references this issue
on Oct 22, 2014
Why we have to quote package names and versions? I mean why we cannot write just
instead of
?
As I understand, neither names nor versions cannot contain whitespaces.