[go-nuts] Re: File organization in a github-ed Go project

2017-03-02 Thread ojucie
That is by design. All import paths should be complete, absolute paths, and 
that is enforced as much as possible.

When somebody moves or copy a file to another directory structure, the 
program behaviour is preserved, even if by chance there is a similarly 
named package nearby.

If "../serial" was allowed, the semantics would be "import any package 
called serial that happens to be found in a sibling directory". By using 
the full path you are stating "I want Basile Starynkevitch's serial 
package. Refuse imitations!"

On Monday, February 27, 2017 at 9:20:44 AM UTC-3, Basile Starynkevitch 
wrote:
>
> I tried (and I would prefer) to code 
>serialmo "../serial"
> but that does not work.
>
>

-- 
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] Re: File organization in a github-ed Go project

2017-02-28 Thread Diego Medina
Note that if you write a project that other users would use, you will force 
them to update their $GOPATH to make your app work.
Which I think it a lot worse than making people who fork your project 
update the import path And like someone else said, if I need to fork a 
project, I most likely already vendor the dependency, so I simply make 
small changes to the file(s) in the vendor folder

Thanks

Diego



On Tuesday, February 28, 2017 at 5:24:28 AM UTC-5, Basile Starynkevitch 
wrote:
>
>
>
> On Monday, February 27, 2017 at 3:18:18 PM UTC+1, Basile Starynkevitch 
> wrote:
>>
>>
>>
>> On Monday, February 27, 2017 at 3:02:24 PM UTC+1, C Banning wrote:
>>>
>>> Try organizing your project as:
>>>
>>> monimelt
>>>
>>> src
>>>
>>> cmd (or "monimelt", if there's just one app)
>>>
>>> objvalmo
>>>
>>> serial 
>>>
>>>  
>>>
>>>  Then include $HOME/monimelt in your GOPATH.
>>>

  
>> Thanks for the suggestion.
>>
>> BTW, I did commit in bbc5c3789788 
>> 
>>  
>> the change of using directory names same as package names. So I have 
>> monimelt/objvalmo/objvalmo.go 
>>  
>> & monimelt/serialmo/serialmo.go 
>>  
>> files (implementing packages objvalmo & serialmo respectively)
>>
>> But does that avoid me to have to use long paths in import directives? 
>> Would that allow me to code import "serialmo" instead of import "
>> github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease 
>> the forking of my github project)?
>>
>> Regards
>>
>> -- 
>> Basile Starynkevitch 
>>
>>
> Actually I did that (adding $HOME/monimelt to my GOPATH)  and now I am 
> simply importing "serialmo"
>
> BTW, I am beginning to believe that I could drop the go tool and use gb 
> build tool  instead.
>

-- 
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] Re: File organization in a github-ed Go project

2017-02-28 Thread Basile Starynkevitch


On Monday, February 27, 2017 at 3:18:18 PM UTC+1, Basile Starynkevitch 
wrote:
>
>
>
> On Monday, February 27, 2017 at 3:02:24 PM UTC+1, C Banning wrote:
>>
>> Try organizing your project as:
>>
>> monimelt
>>
>> src
>>
>> cmd (or "monimelt", if there's just one app)
>>
>> objvalmo
>>
>> serial 
>>
>>  
>>
>>  Then include $HOME/monimelt in your GOPATH.
>>
>>>
>>>  
> Thanks for the suggestion.
>
> BTW, I did commit in bbc5c3789788 
> 
>  
> the change of using directory names same as package names. So I have 
> monimelt/objvalmo/objvalmo.go 
>  & 
> monimelt/serialmo/serialmo.go 
>  
> files (implementing packages objvalmo & serialmo respectively)
>
> But does that avoid me to have to use long paths in import directives? 
> Would that allow me to code import "serialmo" instead of import "
> github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease 
> the forking of my github project)?
>
> Regards
>
> -- 
> Basile Starynkevitch 
>
>
Actually I did that (adding $HOME/monimelt to my GOPATH)  and now I am 
simply importing "serialmo"

BTW, I am beginning to believe that I could drop the go tool and use gb 
build tool  instead.

-- 
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] Re: File organization in a github-ed Go project

2017-02-27 Thread brainman
> if someone wants to fork my github project, he would have change my 
username bstarynk/ by his own one in every package path

When I contribute to other people's projects on Gitub, I just "go get" 
their package, and adjust my "git remote" settings for the package so can 
push all my changes into my Github fork instead. Something 
like 
http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html 
or https://splice.com/blog/contributing-open-source-git-repositories-go/

Alex

-- 
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] Re: File organization in a github-ed Go project

2017-02-27 Thread Basile Starynkevitch


On Monday, February 27, 2017 at 3:02:24 PM UTC+1, C Banning wrote:
>
> Try organizing your project as:
>
> monimelt
>
> src
>
> cmd (or "monimelt", if there's just one app)
>
> objvalmo
>
> serial 
>
>  
>
>  Then include $HOME/monimelt in your GOPATH.
>
>>
>>  
Thanks for the suggestion.

BTW, I did commit in bbc5c3789788 

 
the change of using directory names same as package names. So I have 
monimelt/objvalmo/objvalmo.go 
 & 
monimelt/serialmo/serialmo.go 
 
files (implementing packages objvalmo & serialmo respectively)

But does that avoid me to have to use long paths in import directives? 
Would that allow me to code import "serialmo" instead of import 
"github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease the 
forking of my github project)?

Regards

-- 
Basile Starynkevitch 

-- 
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] Re: File organization in a github-ed Go project

2017-02-27 Thread C Banning
Try organizing your project as:

monimelt

src

cmd (or "monimelt", if there's just one app)

objvalmo

serial 

 

 Then include $HOME/monimelt in your GOPATH.

>
>

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