It seems http://glide.sh is a similar build-your-tree mechanism and does
support redirection. We could always do "put github.com/foo/bar into
launchpad.net/bar".
That would certainly break anything like "go get", so it's something we
probably wouldn't want to overdo. Either that or commit to it
The main problem with putting code into a different directory is that if
there are files in that repo that reference the package itself, they'd need
to be updated.
So like for example, if flag_test.go imports "launchpad.net/gnuflag" to do
external tests, we'd need to edit that code to import
This is why we want to make a juju library, so we have a package that we
know we need to keep backwards compatibility with. Sure, you can vendor or
pin the revision, but that doesn't help you when a new feature or fix lands
and you update, and everything breaks. If we have a library we try to
On Fri, Aug 12, 2016 at 9:11 AM, Nate Finch
wrote:
> The problem really stems from two go-isms -
>
> 1.) The standard for Go projects is to have the path on disk
> representative of the URL to the project.
> 2.) Every file that uses a package has an import statement
On 12 August 2016 at 14:11, Nate Finch wrote:
> No other repo should ever depend on github.com/juju/juju.
I have to call this out. There is no decent way to use Juju from Go without
depending on github.com/juju/juju.
And backward compatibility isn't insurmountable -
On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:
> This is a simple story of a man and a simple mission. Eliminate the final
> 2 dependencies that are in bazaar and launchpad. It makes juju and it's
> dependencies live completely in git. A notable goal, and
This is a simple story of a man and a simple mission. Eliminate the final 2
dependencies that are in bazaar and launchpad. It makes juju and it's
dependencies live completely in git. A notable goal, and one that I desired
for getting snaps to build with launchpad.
I don't feel I need to explain