Re: [Xen-devel] [PATCH] golang/xenlight: Add libxl_utils support

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 7/19/19 11:24 AM, Nicolas Belouin wrote:
> 
> 
> On 7/19/19 12:09 PM, George Dunlap wrote:
>> On 7/19/19 11:03 AM, Nicolas Belouin wrote:
>>>
>>> On 7/19/19 10:50 AM, George Dunlap wrote:
>>>>> On Jul 19, 2019, at 9:47 AM, George Dunlap <george.dunlap@xxxxxxxxxx> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Jul 19, 2019, at 8:34 AM, Nicolas Belouin <nicolas.belouin@xxxxxxxxx> 
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/18/19 11:54 PM, George Dunlap wrote:
>>>>>>> The Go bindings for libxl miss functions from libxl_utils, let's start
>>>>>>> with the simple libxl_domid_to_name and its counterpart
>>>>>>> libxl_name_to_domid.
>>>>>>>
>>>>>>> NB that C.GoString() will return "" if it's passed a NULL; see
>>>>>>> https://github.com/golang/go/issues/32734#issuecomment-506835432
>>>>>>>
>>>>>>> Signed-off-by: Nicolas Belouin <nicolas.belouin@xxxxxxxxx>
>>>>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>>>>> ---
>>>>>>> v3:
>>>>>>> - Wire into build system
>>>>>>> - Add reference to C.GoString() handling NULL to commit message
>>>>>>>
>>>>>>> Nicolas, could you test to see if this actually works for you?
>>>>>> Tested it, it works.
>>>>>>
>>>>>> I must confess I do not use that import path as the new modules mechanism
>>>>>> introduced in Go1.11 downloads and compile a versioned copy of every
>>>>>> dependency per project, and this behavior is incompatible with the build
>>>>>> system used here.
>>>>> It’s possible that something fundamentally has changed, but I suspect 
>>>>> that rather you don’t quite understand how the current build system is 
>>>>> supposed to work.  (In which case a write-up in the tree would probably 
>>>>> be useful.)
>>>>>
>>>>> Go has always insisted that there be no binary compatibility between 
>>>>> versions; so it’s always been necessary to re-compile all your libraries 
>>>>> when upgrading from (say) 1.8 to 1.9.  Which means that any useable 
>>>>> distribution must also include all the source files necessary to 
>>>>> recompile when you bump the version number.
>>>>>
>>>>> So the core mechanism of the “install” is actually to copy all the source 
>>>>> files necessary into the right local directory such that the go compiler 
>>>>> can find them; ATM this is 
>>>>> /usr/share/gocode/golang.xenproject.org/xenlight
>>>> Nit:  This of course should have a `src/` between `gocode/` and 
>>>> `golang.xenproject.org/`.
>>>>
>>>> NB also that this naming scheme was designed so that at some point in the 
>>>> future, we could actually host the xenlight packages at the URL provided.
>>>>
>>>>  -George
>>>>
>>> This new mechanism of modules is described here:
>>> https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more
>>>
>>> The module system is intended to supersede the GOPATH approach and
>>> provide a way to get versioned dependencies, as such
>>> it does not rely on GOPATH at all and doesn't use sources or compiled
>>> packages present in GOPATH elements such as /usr/share/gocode
>>> and systematically fetch (at the asked version) and compile a copy of
>>> the dependency as it might be a different version from the one
>>> in GOPATH.
>>>
>>> As far as I tried, I have been unable to build my module even with the
>>> library installed.
>>> I have to use xenbits.xen.org/git-http/xen.git/tools/golang/xenlight (or
>>> one of its mirror) in order to build the module using the new
>>> mechanism (the golang.xenproject.org/xenlight works when building with
>>> modules mode disabled).
>> I took a look at the module stuff when it came out, and I was never able
>> to make sense of how it was supposed to work.
> Basically it is the same idea than a python virtualenv with
> |include-system-site-packages set to false: never use what is provided
> by the system and download everything in the exact version the manifest
> tells you to.
> |
>> <rant>On the whole, it seems they basically hate the idea of distro
>> packages, and seem intent on breaking them whenever people manage to
>> start to get them working.</rant>
> Actually yes because they don't want to be bound to the version provided
> by the distro (I will not enter the debate of whether it is a good thing
> or not)

If that's a requirement, the distro can provide multiple concurrent
versions.

There are lots of places where build systems aren't allowed to access
the internet.  And distro packages provides lots of useful things:
discoverability, filtering (some level of review has been done to make
sure this code us useful / safe), maintenance (local patches / fixes can
be applied if upstream disappears), decentralization (code is still
available even if upstream goes down / deletes his repositories).

I like Go as a language, but in this particular aspect, the core
developers just seem to be insane.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel