On Tue, Oct 24, 2017 at 10:02 PM, Alex Buchanan wrote:
> Interesting, thanks. Let me try to clarify my idea with some simple code:
>
> // file lives at github.com/buchanae/foobar/foobar.go
> package foobar
>
> func Foobar() string {
> return "foobar"
> }
>
> func main() {
> print(Foobar())
> }
The spec does preclude that since there must be a `package main`.
https://golang.org/ref/spec#Program_execution
On Wed, 2017-10-25 at 05:02 +, Alex Buchanan wrote:
> Interesting, thanks. Let me try to clarify my idea with some simple
> code:
>
> // file lives at github.com/buchanae/foobar/fo
Interesting, thanks. Let me try to clarify my idea with some simple code:
// file lives at github.com/buchanae/foobar/foobar.go
package foobar
func Foobar() string {
return "foobar"
}
func main() {
print(Foobar())
}
This file exports both a function to be used as a library, and a main funct
On Tue, Oct 24, 2017 at 8:14 PM, Alex Buchanan wrote:
>
> Is there documentation (or other) explaining why the main package must have
> name "main" and may not be imported? Is this an important simplification for
> the compiler?
The language spec says that the main package must have the name main
Is there documentation (or other) explaining why the main package must have
name "main" and may not be imported? Is this an important simplification
for the compiler?
I'd love it if a single "go get " represented both my library root and
my command line binary.
On Sunday, September 24, 2017 at
On Sun, Sep 24, 2017 at 5:33 PM, wrote:
>
> The fact that importing a main package in a non main-package isn't supported
> ought to be in the Go spec.
Yes, probably. Want to open an issue about it at https://golang.org/issue ?
Technically, from the language perspective, I think the current
imp
The fact that importing a main package in a non main-package isn't
supported ought to be in the Go spec.
On Thursday, December 15, 2016 at 1:43:45 PM UTC-6, Manlio Perillo wrote:
>
> However importing a main package in another main package works.
> To summarize:
>
> 1) importing a main package in
However importing a main package in another main package works.
To summarize:
1) importing a main package in a external test is supported
2) importing a main package in a main package is supported
3) importing a main package in a non main package is not supported
This seems reasonable to me, howe
On 14 December 2016 at 11:16, roger peppe wrote:
> It is not possible to import main packages in general, although it does
> seem to be possible to import a main package
>
Ah, that explains it. Thanks for the correction. Clearly I never tried
importing a main package from anywhere but its tests
It is not possible to import main packages in general, although it does
seem to be possible to import a main package from external tests in the
same directory.
tst.go: 9:3: import "local/cmd/test" is a program, not an importable package
I'm not why this restriction exists.
On 13 Dec 2016 17:17,
There were some difficulties in writing external tests for a main package,
ie package main_test, but they were resolved a long time ago.
On Wednesday, 14 December 2016 04:18:22 UTC+11, Jan Mercl wrote:
>
> On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
> golan...@googlegroups.com > wr
Il giorno martedì 13 dicembre 2016 18:13:08 UTC+1, adon...@google.com ha
scritto:
>
> On Tuesday, 13 December 2016 11:34:24 UTC-5, Jan Mercl wrote:
>>
>> On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo
>> wrote:
>>
>> > However I think that there is no reason why a "main" package should not
>> b
On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Packages named main are importable, just like any other. Occasionally
this is useful when you want to write tests for members of that package. Of
course, the main function is not exported.
I recall r
On Tuesday, 13 December 2016 11:34:24 UTC-5, Jan Mercl wrote:
>
> On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo > wrote:
>
> > However I think that there is no reason why a "main" package should not
> be importable, to the point that
> > I think that the fact that a "main" package is not importa
On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo
wrote:
> However I think that there is no reason why a "main" package should not
be importable, to the point that
> I think that the fact that a "main" package is not importable is an
"exception" implemented in the Go tool.
The package dependency gr
This is something that I asked in the past, but now it is a feature that I
probably need for a project.
I have a main package with some data fixtures, stored in the package assets
directory.
I want to implement a Go tool that, given a package importpath and a Data
Source Name
(not necessarily a
16 matches
Mail list logo
