On 03/06/2018 01:33 PM, Nicolas Mailhot wrote:
Le 2018-03-06 13:24, Nicolas Mailhot a écrit :
> (really not happy right now about golist trying to parse, install and
> test non production code such as examples, tesdata and _dirs by
> default, all of those should be ignored, trying to parse and install
> them breaks many of our packages, as most example code is quite
> unmaintained by upstreams and will pull needless requires if it does
> work, tesdata is data that will contain broken code if it contains any
> code at all, and _dirs are supposed to be ignored by the compiler so
> trying to parse in in golist often panics.)
I should also say, from a theoretical POW golist may be doing the
right thing, the main difference between Jan and me is that I have a
large pool of specs for existing Go projects, so I tend to notice when
the theory and the practice do not match (like: upstreams commit
working examples, upstreams don't put broken code in testdata of _dirs)
The golist is implemented to recognized the same set of resources as the
upstream go list (since it's built on that). As long as the go list does
not recognizes the testing resources, I can extend the implementation to
go beyond the default go list behavior as we discussed offline. Yet,
providing the solution as an experimental one. I am in favor of
whitelisting anything that we consider as part of the testing or
examples resources. I will need the functionality anyway so all the Go
projects can be processed automatically without a manual intervention.
I want Fedora Go macros that work by default on real-world Go
projects
without needing to specify in all specs to ignore parts we know are
most often broken and clearly unneeded in production.
Regards,