Re: [go-nuts] import a "main" package

2017-10-25 Thread Ian Lance Taylor 
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())
> }
>
> This file exports both a function to be used as a library, and a main 
> function which would be compiled into a command line utility. In order to use 
> the library, you'd write `import "github.com/buchanae/foobar"; 
> foobar.Foobar()`. In order to use the command line tool, you'd run `go get 
> github.com/buchanae/foobar` and run `foobar` on the command line. There's no 
> `import "main"` or package named main in this example. The compiler would 
> need to look for a main function in the starting package and perhaps name 
> symbols using the fully qualified package name. Also, packages in the 
> "foobar" tree would not be importing the root, so there are no import cycles.
>
> I'm not sure it's a good idea, but it was my instinct when I started writing 
> Go, and feels like it would have simplified the organization and 
> documentation of some projects which have a separate "go get " for the 
> library vs the CLI command.

Personally I think it's better to separate the library and the
command.  That is particularly true if the command takes any flags.

> Hope that made sense. Probably too late to be writing about such things :)

Indeed.  It's an interesitng idea but this isn't something that is
going to change at this point.

Ian


> On 10/24/17, 9:31 PM, "Ian Lance Taylor"  wrote:
>
>>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.
>>I guess we could use other mechanisms but that one seems reasonable to
>>me.
>>
>>cmd/compile prohibiting `import "main"` is a moderately important
>>simplification because cmd/compile uses the import path to set symbol
>>names, and for the main package it uses "main".  If cmd/compile
>>permitted `import "main"` then there would be two different packages
>>with the same import path, which can't work.  So it would have to use
>>something else for the imported "main", but what?
>>
>>Note that cmd/compile does not prohibit importing a package named
>>"main" if the path used to import that package is not specifically
>>"main".  But I think the go tool does prohibit that, and I think that
>>is simply to be less surprising to most people.
>>
>>Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2017-10-24 Thread Dan Kortschak 
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/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
> function which would be compiled into a command line utility. In
> order to use the library, you'd write `import
> "github.com/buchanae/foobar"; foobar.Foobar()`. In order to use the
> command line tool, you'd run `go get github.com/buchanae/foobar` and
> run `foobar` on the command line. There's no `import "main"` or
> package named main in this example. The compiler would need to look
> for a main function in the starting package and perhaps name symbols
> using the fully qualified package name. Also, packages in the
> "foobar" tree would not be importing the root, so there are no import
> cycles.
> 
> I'm not sure it's a good idea, but it was my instinct when I started
> writing Go, and feels like it would have simplified the organization
> and documentation of some projects which have a separate "go get
> " for the library vs the CLI command.
> 
> Hope that made sense. Probably too late to be writing about such
> things :)
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2017-10-24 Thread Alex Buchanan 
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 function 
which would be compiled into a command line utility. In order to use the 
library, you'd write `import "github.com/buchanae/foobar"; foobar.Foobar()`. In 
order to use the command line tool, you'd run `go get 
github.com/buchanae/foobar` and run `foobar` on the command line. There's no 
`import "main"` or package named main in this example. The compiler would need 
to look for a main function in the starting package and perhaps name symbols 
using the fully qualified package name. Also, packages in the "foobar" tree 
would not be importing the root, so there are no import cycles.

I'm not sure it's a good idea, but it was my instinct when I started writing 
Go, and feels like it would have simplified the organization and documentation 
of some projects which have a separate "go get " for the library vs the 
CLI command.

Hope that made sense. Probably too late to be writing about such things :)



On 10/24/17, 9:31 PM, "Ian Lance Taylor"  wrote:

>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.
>I guess we could use other mechanisms but that one seems reasonable to
>me.
>
>cmd/compile prohibiting `import "main"` is a moderately important
>simplification because cmd/compile uses the import path to set symbol
>names, and for the main package it uses "main".  If cmd/compile
>permitted `import "main"` then there would be two different packages
>with the same import path, which can't work.  So it would have to use
>something else for the imported "main", but what?
>
>Note that cmd/compile does not prohibit importing a package named
>"main" if the path used to import that package is not specifically
>"main".  But I think the go tool does prohibit that, and I think that
>is simply to be less surprising to most people.
>
>Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2017-10-24 Thread Ian Lance Taylor 
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.
I guess we could use other mechanisms but that one seems reasonable to
me.

cmd/compile prohibiting `import "main"` is a moderately important
simplification because cmd/compile uses the import path to set symbol
names, and for the main package it uses "main".  If cmd/compile
permitted `import "main"` then there would be two different packages
with the same import path, which can't work.  So it would have to use
something else for the imported "main", but what?

Note that cmd/compile does not prohibit importing a package named
"main" if the path used to import that package is not specifically
"main".  But I think the go tool does prohibit that, and I think that
is simply to be less surprising to most people.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2017-09-24 Thread Ian Lance Taylor 
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
implementation forbids literally `import "main"`.  It permits
importing a package whose package name is "main", as long as a
different path is used to import it.  The go tool may impose other
restrictions--offhand I don't recall--but those restrictions, if any,
don't necessarily belong in the language spec.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2017-09-24 Thread beach144 
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 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, however AFAIK it is not documented.
>
> Manlio
>
> Il giorno mercoledì 14 dicembre 2016 17:17:14 UTC+1, rog ha scritto:
>>
>> 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, "Jan Mercl" <0xj...@gmail.com> wrote:
>>
>>> On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
>>> golan...@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 running into this limitation years ago. Was it always possible? 
>>> Or do I have a false remembrance?
>>>
>>> -- 
>>>
>>> -j
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-15 Thread Manlio Perillo 
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, however AFAIK it is not documented.

Manlio

Il giorno mercoledì 14 dicembre 2016 17:17:14 UTC+1, rog ha scritto:
>
> 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, "Jan Mercl" <0xj...@gmail.com > wrote:
>
>> On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
>> golan...@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 running into this limitation years ago. Was it always possible? 
>> Or do I have a false remembrance?
>>
>> -- 
>>
>> -j
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-14 Thread 'Alan Donovan' via golang-nuts 
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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-14 Thread roger peppe 
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, "Jan Mercl" <0xj...@gmail.com> wrote:

> 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 running into this limitation years ago. Was it always possible?
> Or do I have a false remembrance?
>
> --
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-13 Thread Dave Cheney 
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 > 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 running into this limitation years ago. Was it always possible? 
> Or do I have a false remembrance?
>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-13 Thread Jan Mercl 
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 running into this limitation years ago. Was it always possible? Or
do I have a false remembrance?

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-13 Thread adonovan via golang-nuts 
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 importable is an 
> "exception" implemented in the Go tool.
>
> The package dependency graph must be (1) an acyclic graph, ie. a tree with 
> (2) main package at its root, for obvious reasons. Importing main violates 
> both of the properties.
>

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.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] import a "main" package

2016-12-13 Thread Jan Mercl 
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 graph must be (1) an acyclic graph, ie. a tree with
(2) main package at its root, for obvious reasons. Importing main violates
both of the properties.
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] import a "main" package

2016-12-13 Thread Manlio Perillo 
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 an SQL database), loads the data fixtures in the database.

Each fixture file is named after the name of a Go struct, so the tool will 
generate, build and run a Go
source where the package is imported, the data fixture is decoded into a Go 
variable, and then
saved in the database.

This is easy, but the problem is that a main package can not be imported.
Of course I can move the related code to a normal package; and this may 
also improve the code organization.

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.

Is this true?


Thanks  Manlio

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.