You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Robert Burke <ro...@frantil.com> on 2018/04/16 23:56:45 UTC

[Go SDK] Proposal: Set up a Vanity Import Path

Hi All!
While the Go SDK is still experimental, that doesn't mean it shouldn't be
future proofed.

Go has the ability to specify custom import paths for a prefix of packages.
This has benefits of avoiding generic GitHub paths, and avoids breaking
users in the event of infrastructure events such as moving off of GitHub,
or even splitting the repo into per language components.

Currently users need to import paths like:

import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"

to get at SDK packages. If we implement this proposal, they would look like:

import "beam.apache.org/sdks/go/pkg/beam/io/textio"

which are a bit shorter, a bit more stable, and a bit nicer, with the
benefits outlined above.

I wrote a doc with details which is at
https://s.apache.org/go-beam-vanity-import
(Thanks you Thomas for short linking it for me.)

The doc should answer most of your questions, but please let me know if you
have others either here, or in a doc comment.

If there's consensus to do so, it would be better it's done sooner rather
than after folks begin depending on it. We wouldn't want to have fragmented
examples.

Robert Burke
(One of the Gopher Googlers who have been quietly lurking on the list, and
submitting the occasional PR for the Go SDK. I look forward to working with
you all!)

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Jason Kuster <ja...@google.com>.
+1 this will be very convenient for the go community.

On Thu, Apr 19, 2018 at 2:21 PM Henning Rohde <he...@google.com> wrote:

> +1 Great proposal!
>
> On Wed, Apr 18, 2018 at 1:37 PM Ismaël Mejía <ie...@gmail.com> wrote:
>
>> Well it is not really a rule for a proposal but notice that there are
>> people in different time zones or people that for different reasons
>> cannot answer immediately, so a longer period could give them a chance
>> to voice their opinions.
>>
>> On Wed, Apr 18, 2018 at 10:23 PM, Robert Burke <ro...@frantil.com>
>> wrote:
>> > That's good to know!
>> > I had heard of that specific rule, but I didn't realized it pertained to
>> > filing of a JIRA issue (when related to a proposal) as well.
>> > Thank you.
>> >
>> > On Wed, 18 Apr 2018 at 13:08 Ismaël Mejía <ie...@gmail.com> wrote:
>> >>
>> >> +1 Nice idea and proposal.
>> >>
>> >> This was not a vote thread but for the future it is a good idea to let
>> >> a bigger time window before reaching consensus.
>> >> Notice that a formal vote lets at least 72h for participants to voice
>> >> their opinion before concluding something.
>> >>
>> >> https://www.apache.org/foundation/voting.html
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Apr 18, 2018 at 6:29 PM, Robert Burke <ro...@frantil.com>
>> wrote:
>> >> > This seems like enough consensus to file the JIRA, so
>> >> > https://issues.apache.org/jira/browse/BEAM-4115 has now been
>> created.
>> >> >
>> >> > I'll get to work on the PRs shortly.
>> >> >
>> >> > Cheers,
>> >> > Robert Burke
>> >> >
>> >> > On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> >> > wrote:
>> >> >>
>> >> >> +1
>> >> >>
>> >> >> Agree
>> >> >> Regards
>> >> >> JB
>> >> >> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a
>> >> >> écrit:
>> >> >>>
>> >> >>> +1 this sounds super reasonable
>> >> >>>
>> >> >>>
>> >> >>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
>> >> >>>
>> >> >>> This seems like a valuable layer of indirection to establish. The
>> >> >>> mechanisms are pretty esoteric, but I trust Gophers to know the
>> best
>> >> >>> way to
>> >> >>> do it. Commented just a smidgin on the doc.
>> >> >>>
>> >> >>> Kenn
>> >> >>>
>> >> >>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Hi All!
>> >> >>>> While the Go SDK is still experimental, that doesn't mean it
>> >> >>>> shouldn't
>> >> >>>> be future proofed.
>> >> >>>>
>> >> >>>> Go has the ability to specify custom import paths for a prefix of
>> >> >>>> packages. This has benefits of avoiding generic GitHub paths, and
>> >> >>>> avoids
>> >> >>>> breaking users in the event of infrastructure events such as
>> moving
>> >> >>>> off of
>> >> >>>> GitHub, or even splitting the repo into per language components.
>> >> >>>>
>> >> >>>> Currently users need to import paths like:
>> >> >>>>
>> >> >>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
>> >> >>>>
>> >> >>>> to get at SDK packages. If we implement this proposal, they would
>> >> >>>> look
>> >> >>>> like:
>> >> >>>>
>> >> >>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
>> >> >>>>
>> >> >>>> which are a bit shorter, a bit more stable, and a bit nicer, with
>> the
>> >> >>>> benefits outlined above.
>> >> >>>>
>> >> >>>> I wrote a doc with details which is at
>> >> >>>> https://s.apache.org/go-beam-vanity-import
>> >> >>>> (Thanks you Thomas for short linking it for me.)
>> >> >>>>
>> >> >>>> The doc should answer most of your questions, but please let me
>> know
>> >> >>>> if
>> >> >>>> you have others either here, or in a doc comment.
>> >> >>>>
>> >> >>>> If there's consensus to do so, it would be better it's done sooner
>> >> >>>> rather than after folks begin depending on it. We wouldn't want to
>> >> >>>> have
>> >> >>>> fragmented examples.
>> >> >>>>
>> >> >>>> Robert Burke
>> >> >>>> (One of the Gopher Googlers who have been quietly lurking on the
>> >> >>>> list,
>> >> >>>> and submitting the occasional PR for the Go SDK. I look forward to
>> >> >>>> working
>> >> >>>> with you all!)
>> >> >>>
>> >> >>>
>> >> >
>>
>

-- 
-------
Jason Kuster
Apache Beam / Google Cloud Dataflow

See something? Say something. go/jasonkuster-feedback

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Henning Rohde <he...@google.com>.
+1 Great proposal!

On Wed, Apr 18, 2018 at 1:37 PM Ismaël Mejía <ie...@gmail.com> wrote:

> Well it is not really a rule for a proposal but notice that there are
> people in different time zones or people that for different reasons
> cannot answer immediately, so a longer period could give them a chance
> to voice their opinions.
>
> On Wed, Apr 18, 2018 at 10:23 PM, Robert Burke <ro...@frantil.com> wrote:
> > That's good to know!
> > I had heard of that specific rule, but I didn't realized it pertained to
> > filing of a JIRA issue (when related to a proposal) as well.
> > Thank you.
> >
> > On Wed, 18 Apr 2018 at 13:08 Ismaël Mejía <ie...@gmail.com> wrote:
> >>
> >> +1 Nice idea and proposal.
> >>
> >> This was not a vote thread but for the future it is a good idea to let
> >> a bigger time window before reaching consensus.
> >> Notice that a formal vote lets at least 72h for participants to voice
> >> their opinion before concluding something.
> >>
> >> https://www.apache.org/foundation/voting.html
> >>
> >>
> >>
> >>
> >> On Wed, Apr 18, 2018 at 6:29 PM, Robert Burke <ro...@frantil.com>
> wrote:
> >> > This seems like enough consensus to file the JIRA, so
> >> > https://issues.apache.org/jira/browse/BEAM-4115 has now been created.
> >> >
> >> > I'll get to work on the PRs shortly.
> >> >
> >> > Cheers,
> >> > Robert Burke
> >> >
> >> > On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> > wrote:
> >> >>
> >> >> +1
> >> >>
> >> >> Agree
> >> >> Regards
> >> >> JB
> >> >> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a
> >> >> écrit:
> >> >>>
> >> >>> +1 this sounds super reasonable
> >> >>>
> >> >>>
> >> >>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
> >> >>>
> >> >>> This seems like a valuable layer of indirection to establish. The
> >> >>> mechanisms are pretty esoteric, but I trust Gophers to know the best
> >> >>> way to
> >> >>> do it. Commented just a smidgin on the doc.
> >> >>>
> >> >>> Kenn
> >> >>>
> >> >>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com>
> >> >>> wrote:
> >> >>>>
> >> >>>> Hi All!
> >> >>>> While the Go SDK is still experimental, that doesn't mean it
> >> >>>> shouldn't
> >> >>>> be future proofed.
> >> >>>>
> >> >>>> Go has the ability to specify custom import paths for a prefix of
> >> >>>> packages. This has benefits of avoiding generic GitHub paths, and
> >> >>>> avoids
> >> >>>> breaking users in the event of infrastructure events such as moving
> >> >>>> off of
> >> >>>> GitHub, or even splitting the repo into per language components.
> >> >>>>
> >> >>>> Currently users need to import paths like:
> >> >>>>
> >> >>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
> >> >>>>
> >> >>>> to get at SDK packages. If we implement this proposal, they would
> >> >>>> look
> >> >>>> like:
> >> >>>>
> >> >>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
> >> >>>>
> >> >>>> which are a bit shorter, a bit more stable, and a bit nicer, with
> the
> >> >>>> benefits outlined above.
> >> >>>>
> >> >>>> I wrote a doc with details which is at
> >> >>>> https://s.apache.org/go-beam-vanity-import
> >> >>>> (Thanks you Thomas for short linking it for me.)
> >> >>>>
> >> >>>> The doc should answer most of your questions, but please let me
> know
> >> >>>> if
> >> >>>> you have others either here, or in a doc comment.
> >> >>>>
> >> >>>> If there's consensus to do so, it would be better it's done sooner
> >> >>>> rather than after folks begin depending on it. We wouldn't want to
> >> >>>> have
> >> >>>> fragmented examples.
> >> >>>>
> >> >>>> Robert Burke
> >> >>>> (One of the Gopher Googlers who have been quietly lurking on the
> >> >>>> list,
> >> >>>> and submitting the occasional PR for the Go SDK. I look forward to
> >> >>>> working
> >> >>>> with you all!)
> >> >>>
> >> >>>
> >> >
>

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Ismaël Mejía <ie...@gmail.com>.
Well it is not really a rule for a proposal but notice that there are
people in different time zones or people that for different reasons
cannot answer immediately, so a longer period could give them a chance
to voice their opinions.

On Wed, Apr 18, 2018 at 10:23 PM, Robert Burke <ro...@frantil.com> wrote:
> That's good to know!
> I had heard of that specific rule, but I didn't realized it pertained to
> filing of a JIRA issue (when related to a proposal) as well.
> Thank you.
>
> On Wed, 18 Apr 2018 at 13:08 Ismaël Mejía <ie...@gmail.com> wrote:
>>
>> +1 Nice idea and proposal.
>>
>> This was not a vote thread but for the future it is a good idea to let
>> a bigger time window before reaching consensus.
>> Notice that a formal vote lets at least 72h for participants to voice
>> their opinion before concluding something.
>>
>> https://www.apache.org/foundation/voting.html
>>
>>
>>
>>
>> On Wed, Apr 18, 2018 at 6:29 PM, Robert Burke <ro...@frantil.com> wrote:
>> > This seems like enough consensus to file the JIRA, so
>> > https://issues.apache.org/jira/browse/BEAM-4115 has now been created.
>> >
>> > I'll get to work on the PRs shortly.
>> >
>> > Cheers,
>> > Robert Burke
>> >
>> > On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net>
>> > wrote:
>> >>
>> >> +1
>> >>
>> >> Agree
>> >> Regards
>> >> JB
>> >> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a
>> >> écrit:
>> >>>
>> >>> +1 this sounds super reasonable
>> >>>
>> >>>
>> >>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
>> >>>
>> >>> This seems like a valuable layer of indirection to establish. The
>> >>> mechanisms are pretty esoteric, but I trust Gophers to know the best
>> >>> way to
>> >>> do it. Commented just a smidgin on the doc.
>> >>>
>> >>> Kenn
>> >>>
>> >>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com>
>> >>> wrote:
>> >>>>
>> >>>> Hi All!
>> >>>> While the Go SDK is still experimental, that doesn't mean it
>> >>>> shouldn't
>> >>>> be future proofed.
>> >>>>
>> >>>> Go has the ability to specify custom import paths for a prefix of
>> >>>> packages. This has benefits of avoiding generic GitHub paths, and
>> >>>> avoids
>> >>>> breaking users in the event of infrastructure events such as moving
>> >>>> off of
>> >>>> GitHub, or even splitting the repo into per language components.
>> >>>>
>> >>>> Currently users need to import paths like:
>> >>>>
>> >>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
>> >>>>
>> >>>> to get at SDK packages. If we implement this proposal, they would
>> >>>> look
>> >>>> like:
>> >>>>
>> >>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
>> >>>>
>> >>>> which are a bit shorter, a bit more stable, and a bit nicer, with the
>> >>>> benefits outlined above.
>> >>>>
>> >>>> I wrote a doc with details which is at
>> >>>> https://s.apache.org/go-beam-vanity-import
>> >>>> (Thanks you Thomas for short linking it for me.)
>> >>>>
>> >>>> The doc should answer most of your questions, but please let me know
>> >>>> if
>> >>>> you have others either here, or in a doc comment.
>> >>>>
>> >>>> If there's consensus to do so, it would be better it's done sooner
>> >>>> rather than after folks begin depending on it. We wouldn't want to
>> >>>> have
>> >>>> fragmented examples.
>> >>>>
>> >>>> Robert Burke
>> >>>> (One of the Gopher Googlers who have been quietly lurking on the
>> >>>> list,
>> >>>> and submitting the occasional PR for the Go SDK. I look forward to
>> >>>> working
>> >>>> with you all!)
>> >>>
>> >>>
>> >

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Robert Burke <ro...@frantil.com>.
That's good to know!
I had heard of that specific rule, but I didn't realized it pertained to
filing of a JIRA issue (when related to a proposal) as well.
Thank you.

On Wed, 18 Apr 2018 at 13:08 Ismaël Mejía <ie...@gmail.com> wrote:

> +1 Nice idea and proposal.
>
> This was not a vote thread but for the future it is a good idea to let
> a bigger time window before reaching consensus.
> Notice that a formal vote lets at least 72h for participants to voice
> their opinion before concluding something.
>
> https://www.apache.org/foundation/voting.html
>
>
>
>
> On Wed, Apr 18, 2018 at 6:29 PM, Robert Burke <ro...@frantil.com> wrote:
> > This seems like enough consensus to file the JIRA, so
> > https://issues.apache.org/jira/browse/BEAM-4115 has now been created.
> >
> > I'll get to work on the PRs shortly.
> >
> > Cheers,
> > Robert Burke
> >
> > On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >>
> >> +1
> >>
> >> Agree
> >> Regards
> >> JB
> >> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a
> écrit:
> >>>
> >>> +1 this sounds super reasonable
> >>>
> >>>
> >>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
> >>>
> >>> This seems like a valuable layer of indirection to establish. The
> >>> mechanisms are pretty esoteric, but I trust Gophers to know the best
> way to
> >>> do it. Commented just a smidgin on the doc.
> >>>
> >>> Kenn
> >>>
> >>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com>
> wrote:
> >>>>
> >>>> Hi All!
> >>>> While the Go SDK is still experimental, that doesn't mean it shouldn't
> >>>> be future proofed.
> >>>>
> >>>> Go has the ability to specify custom import paths for a prefix of
> >>>> packages. This has benefits of avoiding generic GitHub paths, and
> avoids
> >>>> breaking users in the event of infrastructure events such as moving
> off of
> >>>> GitHub, or even splitting the repo into per language components.
> >>>>
> >>>> Currently users need to import paths like:
> >>>>
> >>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
> >>>>
> >>>> to get at SDK packages. If we implement this proposal, they would look
> >>>> like:
> >>>>
> >>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
> >>>>
> >>>> which are a bit shorter, a bit more stable, and a bit nicer, with the
> >>>> benefits outlined above.
> >>>>
> >>>> I wrote a doc with details which is at
> >>>> https://s.apache.org/go-beam-vanity-import
> >>>> (Thanks you Thomas for short linking it for me.)
> >>>>
> >>>> The doc should answer most of your questions, but please let me know
> if
> >>>> you have others either here, or in a doc comment.
> >>>>
> >>>> If there's consensus to do so, it would be better it's done sooner
> >>>> rather than after folks begin depending on it. We wouldn't want to
> have
> >>>> fragmented examples.
> >>>>
> >>>> Robert Burke
> >>>> (One of the Gopher Googlers who have been quietly lurking on the list,
> >>>> and submitting the occasional PR for the Go SDK. I look forward to
> working
> >>>> with you all!)
> >>>
> >>>
> >
>

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Ismaël Mejía <ie...@gmail.com>.
+1 Nice idea and proposal.

This was not a vote thread but for the future it is a good idea to let
a bigger time window before reaching consensus.
Notice that a formal vote lets at least 72h for participants to voice
their opinion before concluding something.

https://www.apache.org/foundation/voting.html




On Wed, Apr 18, 2018 at 6:29 PM, Robert Burke <ro...@frantil.com> wrote:
> This seems like enough consensus to file the JIRA, so
> https://issues.apache.org/jira/browse/BEAM-4115 has now been created.
>
> I'll get to work on the PRs shortly.
>
> Cheers,
> Robert Burke
>
> On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> +1
>>
>> Agree
>> Regards
>> JB
>> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a écrit:
>>>
>>> +1 this sounds super reasonable
>>>
>>>
>>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
>>>
>>> This seems like a valuable layer of indirection to establish. The
>>> mechanisms are pretty esoteric, but I trust Gophers to know the best way to
>>> do it. Commented just a smidgin on the doc.
>>>
>>> Kenn
>>>
>>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com> wrote:
>>>>
>>>> Hi All!
>>>> While the Go SDK is still experimental, that doesn't mean it shouldn't
>>>> be future proofed.
>>>>
>>>> Go has the ability to specify custom import paths for a prefix of
>>>> packages. This has benefits of avoiding generic GitHub paths, and avoids
>>>> breaking users in the event of infrastructure events such as moving off of
>>>> GitHub, or even splitting the repo into per language components.
>>>>
>>>> Currently users need to import paths like:
>>>>
>>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
>>>>
>>>> to get at SDK packages. If we implement this proposal, they would look
>>>> like:
>>>>
>>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
>>>>
>>>> which are a bit shorter, a bit more stable, and a bit nicer, with the
>>>> benefits outlined above.
>>>>
>>>> I wrote a doc with details which is at
>>>> https://s.apache.org/go-beam-vanity-import
>>>> (Thanks you Thomas for short linking it for me.)
>>>>
>>>> The doc should answer most of your questions, but please let me know if
>>>> you have others either here, or in a doc comment.
>>>>
>>>> If there's consensus to do so, it would be better it's done sooner
>>>> rather than after folks begin depending on it. We wouldn't want to have
>>>> fragmented examples.
>>>>
>>>> Robert Burke
>>>> (One of the Gopher Googlers who have been quietly lurking on the list,
>>>> and submitting the occasional PR for the Go SDK. I look forward to working
>>>> with you all!)
>>>
>>>
>

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Robert Burke <ro...@frantil.com>.
This seems like enough consensus to file the JIRA, so
https://issues.apache.org/jira/browse/BEAM-4115 has now been created.

I'll get to work on the PRs shortly.

Cheers,
Robert Burke

On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> +1
>
> Agree
> Regards
> JB
> Le 18 avr. 2018, à 14:51, Aljoscha Krettek <al...@apache.org> a écrit:
>>
>> +1 this sounds super reasonable
>>
>>
>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
>>
>> This seems like a valuable layer of indirection to establish. The
>> mechanisms are pretty esoteric, but I trust Gophers to know the best way to
>> do it. Commented just a smidgin on the doc.
>>
>> Kenn
>>
>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com> wrote:
>>
>>> Hi All!
>>> While the Go SDK is still experimental, that doesn't mean it shouldn't
>>> be future proofed.
>>>
>>> Go has the ability to specify custom import paths for a prefix of
>>> packages. This has benefits of avoiding generic GitHub paths, and avoids
>>> breaking users in the event of infrastructure events such as moving off of
>>> GitHub, or even splitting the repo into per language components.
>>>
>>> Currently users need to import paths like:
>>>
>>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
>>>
>>> to get at SDK packages. If we implement this proposal, they would look
>>> like:
>>>
>>> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
>>>
>>> which are a bit shorter, a bit more stable, and a bit nicer, with the
>>> benefits outlined above.
>>>
>>> I wrote a doc with details which is at
>>> https://s.apache.org/go-beam-vanity-import
>>> (Thanks you Thomas for short linking it for me.)
>>>
>>> The doc should answer most of your questions, but please let me know if
>>> you have others either here, or in a doc comment.
>>>
>>> If there's consensus to do so, it would be better it's done sooner
>>> rather than after folks begin depending on it. We wouldn't want to have
>>> fragmented examples.
>>>
>>> Robert Burke
>>> (One of the Gopher Googlers who have been quietly lurking on the list,
>>> and submitting the occasional PR for the Go SDK. I look forward to working
>>> with you all!)
>>>
>>
>>

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1

Agree
Regards
JB

Le 18 avr. 2018 à 14:51, à 14:51, Aljoscha Krettek <al...@apache.org> a écrit:
>+1 this sounds super reasonable
>
>
>> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
>> 
>> This seems like a valuable layer of indirection to establish. The
>mechanisms are pretty esoteric, but I trust Gophers to know the best
>way to do it. Commented just a smidgin on the doc.
>> 
>> Kenn
>> 
>> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <robert@frantil.com
><ma...@frantil.com>> wrote:
>> Hi All!
>> While the Go SDK is still experimental, that doesn't mean it
>shouldn't be future proofed.
>> 
>> Go has the ability to specify custom import paths for a prefix of
>packages. This has benefits of avoiding generic GitHub paths, and
>avoids breaking users in the event of infrastructure events such as
>moving off of GitHub, or even splitting the repo into per language
>components.
>> 
>> Currently users need to import paths like:
>> 
>> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio
><http://github.com/apache/beam/sdks/go/pkg/beam/io/textio>"
>> 
>> to get at SDK packages. If we implement this proposal, they would
>look like:
>> 
>> import "beam.apache.org/sdks/go/pkg/beam/io/textio
><http://beam.apache.org/sdks/go/pkg/beam/io/textio>"
>> 
>> which are a bit shorter, a bit more stable, and a bit nicer, with the
>benefits outlined above.
>> 
>> I wrote a doc with details which is at
>https://s.apache.org/go-beam-vanity-import
><https://s.apache.org/go-beam-vanity-import> 
>> (Thanks you Thomas for short linking it for me.)
>> 
>> The doc should answer most of your questions, but please let me know
>if you have others either here, or in a doc comment.
>> 
>> If there's consensus to do so, it would be better it's done sooner
>rather than after folks begin depending on it. We wouldn't want to have
>fragmented examples.
>> 
>> Robert Burke
>> (One of the Gopher Googlers who have been quietly lurking on the
>list, and submitting the occasional PR for the Go SDK. I look forward
>to working with you all!)

Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Aljoscha Krettek <al...@apache.org>.
+1 this sounds super reasonable


> On 17. Apr 2018, at 20:11, Kenneth Knowles <kl...@google.com> wrote:
> 
> This seems like a valuable layer of indirection to establish. The mechanisms are pretty esoteric, but I trust Gophers to know the best way to do it. Commented just a smidgin on the doc.
> 
> Kenn
> 
> On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <robert@frantil.com <ma...@frantil.com>> wrote:
> Hi All!
> While the Go SDK is still experimental, that doesn't mean it shouldn't be future proofed.
> 
> Go has the ability to specify custom import paths for a prefix of packages. This has benefits of avoiding generic GitHub paths, and avoids breaking users in the event of infrastructure events such as moving off of GitHub, or even splitting the repo into per language components.
> 
> Currently users need to import paths like:
> 
> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio <http://github.com/apache/beam/sdks/go/pkg/beam/io/textio>"
> 
> to get at SDK packages. If we implement this proposal, they would look like:
> 
> import "beam.apache.org/sdks/go/pkg/beam/io/textio <http://beam.apache.org/sdks/go/pkg/beam/io/textio>"
> 
> which are a bit shorter, a bit more stable, and a bit nicer, with the benefits outlined above.
> 
> I wrote a doc with details which is at https://s.apache.org/go-beam-vanity-import <https://s.apache.org/go-beam-vanity-import> 
> (Thanks you Thomas for short linking it for me.)
> 
> The doc should answer most of your questions, but please let me know if you have others either here, or in a doc comment.
> 
> If there's consensus to do so, it would be better it's done sooner rather than after folks begin depending on it. We wouldn't want to have fragmented examples.
> 
> Robert Burke
> (One of the Gopher Googlers who have been quietly lurking on the list, and submitting the occasional PR for the Go SDK. I look forward to working with you all!)


Re: [Go SDK] Proposal: Set up a Vanity Import Path

Posted by Kenneth Knowles <kl...@google.com>.
This seems like a valuable layer of indirection to establish. The
mechanisms are pretty esoteric, but I trust Gophers to know the best way to
do it. Commented just a smidgin on the doc.

Kenn

On Mon, Apr 16, 2018 at 4:57 PM Robert Burke <ro...@frantil.com> wrote:

> Hi All!
> While the Go SDK is still experimental, that doesn't mean it shouldn't be
> future proofed.
>
> Go has the ability to specify custom import paths for a prefix of
> packages. This has benefits of avoiding generic GitHub paths, and avoids
> breaking users in the event of infrastructure events such as moving off of
> GitHub, or even splitting the repo into per language components.
>
> Currently users need to import paths like:
>
> import "github.com/apache/beam/sdks/go/pkg/beam/io/textio"
>
> to get at SDK packages. If we implement this proposal, they would look
> like:
>
> import "beam.apache.org/sdks/go/pkg/beam/io/textio"
>
> which are a bit shorter, a bit more stable, and a bit nicer, with the
> benefits outlined above.
>
> I wrote a doc with details which is at
> https://s.apache.org/go-beam-vanity-import
> (Thanks you Thomas for short linking it for me.)
>
> The doc should answer most of your questions, but please let me know if
> you have others either here, or in a doc comment.
>
> If there's consensus to do so, it would be better it's done sooner rather
> than after folks begin depending on it. We wouldn't want to have fragmented
> examples.
>
> Robert Burke
> (One of the Gopher Googlers who have been quietly lurking on the list, and
> submitting the occasional PR for the Go SDK. I look forward to working with
> you all!)
>