[Bug 226290] [NEW PORT] devel/py-python-gitlab: Python package providing access to the GitLab server API

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226290

--- Comment #5 from Kubilay Kocak <koobs at FreeBSD.org> ---
(In reply to dereks from comment #4)

pkg-descr: long_description, formatted well, if there is one. otherwise some
upstream source that provides a nice initial summary, formatted nicely if
necessary. if no upstream source exists, creative license/common sense and send
them a PR to add it :)

TEST_DEPENDS: These dont block landing your changes, but its good to get into
the habit of adding test framework bits (TEST_DEPENDS/test: target) early.

conflicts/conncurrency: USE_PYTHON=concurrent should handle most if not all of
it. It definitely handles stuff installed in LOCALBASE/bin.

Re testing/building with other python versions:

- In LOCALBASE/etc/poudriere.d/py36.conf
- Add DEFAULT_VERSIONS=python=x.y
- poudriere testport -o <origin> -z py36

You can create as many *.conf's as you want, and use them in -z <set> args.

Ignore the symlinks in those cases, the framework does the right thing for the
(ports) users DEFAULT_VERSIONN, and for package users, we only produce packages
for the default default_Version (2.7), so 3.x packages (if they were built),
wont contain them.

patches: Generally, ideally yes, less maintenance long term, relationship++
with upstreams. In this patches case, its a hardcoded default. The package
could support some form of configuration that can be set at build time so the
right (custom) path is set wherever it needs to be. The post-patch is fine for
now. The upstream issue summary might look something like "Provide mechanism to
replace hardcoded /etc dir" or similar

-- 
You are receiving this mail because:
You are the assignee for the bug.