search

gofed / go-macros

Rpm mechanics for Go packaging
4 stars 7 forks source link

Fix splitting of sub-import paths in separate packages #37

Closed nim-nim closed 5 years ago

nim-nim commented 6 years ago

I needed to package a project subtree separately, as it pulled in problem dependencies, and the existing code proved totally broken in practice.

This fixed version works for me.

I honestly do not see the point of the last_goipath and golistflags[$_last_goipath] stuff from line 137 onwards. IMHO it adds a lot of complexity and there’s no way it can actually work as intended in presence of default exclusion flags. However, it didn't prevent my subpackaging as a separate import path so I let it in.

Please check again if you actually need this with the fix I'm posting here. If not, please remove the per-goipath array indexing and make back the -d and -t exclusion flags as relative to the project root.

With or without the per-goipath exclusion array this fix is needed for the logic to actually work

ingvagabund commented 6 years ago

I merged the blocking part: https://github.com/gofed/go-macros/commit/c259c4ed880d10667974c460e5259605e32330f0

nim-nim commented 6 years ago

6750cdf4ca0ac93d6692f89161f2c2d3129b5fd1 should fix all problems the way you wanted

nim-nim commented 6 years ago

Hi,

This PR is required to solve cleanly the packaging of golang projects with complex dependencies (core projects like golang/x for example)

It is still not merged with no feedback :(

Since it was submitted, the following conflicting commits were added to the repo: 44a2515165e665d740aabe711f4a1987a104a987 4d469a3d37c21353fbd6bb306ce707dc4151fd1e

I do not understand the point of those commits:

  1. they add metadata info inside the .goipath file, that you didn't want to do before, which is why 3c03f6264c3f596ce81f54f939a7d3303d9cbb06 uses a separate file

  2. they are an awful manual kludge to expose commit info that is already available reliably in rpm metadata (and rpm metadata does not posits everything is a commit, so the kludge won't work for tags and releases which should be our primary target)

  3. if you wanted to handle splitting of a project in several subtrees, that's the whole point of the PR you didn't merge yet

  4. if you wanted to handle the grafting of a separate project inside a project tree, it's awful malpractice to do it from the same spec file (just package the separate project in a separate spec, and use bootstraping in case of dep loops), that only ends up in breakage right and left, but even if you did want to do it there's no way the grafted tree is going to share the same root, it will either be a totally separate root or a subroot to the goipath files can not collision

So, what is the use case exactly and why is the existing logic insufficient? Right those commits feel like evil confused logic that should be dropped instead of rebasing PR's on top of them