Bug 234816 - [NEW PORT] sysutils/ioc: CLI tool for jail management with libioc{age,ell}
Summary: [NEW PORT] sysutils/ioc: CLI tool for jail management with libioc{age,ell}
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL: https://github.com/bsdci/ioc
Keywords: needs-patch, needs-qa
Depends on: 234812
Blocks:
  Show dependency treegraph
 
Reported: 2019-01-10 09:05 UTC by gronke
Modified: 2019-02-08 20:51 UTC (History)
4 users (show)

See Also:
koobs: maintainer-feedback? (stefan)


Attachments
sysutils/ioc ports package (3.03 KB, text/plain)
2019-01-10 09:30 UTC, gronke
no flags Details
sysutils/ioc ports package (4.46 KB, text/plain)
2019-01-12 09:17 UTC, gronke
no flags Details
sysutils/ioc ports package (4.46 KB, text/plain)
2019-02-08 20:51 UTC, gronke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gronke 2019-01-10 09:05:00 UTC
ioc is a jail manager based on the idea of iocage and iocell. This package provides a command line utility that uses libioc to manage jails, compatible with iocage_legacy, iocell and python-iocage (<1.0). An improved user interface and a the robustness of the object-oriented Python library can replace other CLI variants or be used in conjunction.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-01-10 09:25:54 UTC

If the ioc cli tool/package depends on, but isn't provided by the libioc package/code, is there a patch that was supposed to be attached here?

If the ioc cli is provided by the libioc package in bug 234812, then this issue is not necessary, as packages are automatically created for each port (packages are just pre-compiled ports)
Comment 2 gronke 2019-01-10 09:30:11 UTC
Created attachment 200980 [details]
sysutils/ioc ports package
Comment 3 gronke 2019-01-10 09:33:07 UTC
Oh yes, there should have been an attachment in first place.

The Python module and this CLI tool should be separate packages. This one for example is not prefixed with py36- because it does not install any python module, although it depends on py36-ioc. There are use-cases where one only want to script jails, but not use the command line utility at all.
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2019-01-12 03:30:49 UTC
Some review items:

- Python ports should almost always be prefixed with PKGNAMEPREFIX=PYTHON_PKGNAMEPREFIX. This is particularly the case with ports (python packages) that support multiple Python versions, which is almost every python software in existence.

- If pip isn't a *_DEPENDS, remove the commented line, or comment above the commented line as to why it's commented (not yet ported, future reference, whatever)

- Add python as a secondary (virtual) CATEGORIES

- NO_BUILD=yes - replace with USE_PYTHON=distutils autoplist (variable is currently defined but empty incorrectly). Python packages that support these mechanisms should use them in their ports, as it ensures a standard and consistent build / installation, without manual porting. This also obviates the need to use the custom do-install targets/entries, which are not currently installing things into the correct places (PREFIX/lib, not in the python site-packages dir)

- Use USE_RC_SUBR for the rc.d script, after copying the file from WRKSRC to files/ (FILESDIR) at post-extract: time. See: https://www.freebsd.org/doc/en/books/porters-handbook/book.html#rc-scripts

- The PORTNAME is not consistent with the setup.py:name (ioc_cli). Since the latter should/will be registered in PyPI (sdist distribution not withstanding), the PORTNAME should match what will eventually be its canonical name.

More broadly, there is a naming conflict/confusion created between this and the dependent port (in bug 234812) born purely from the lack of a prefix (see above).

I would standardize/canonicalize the upstream naming, and re-submit patches/port names as follows (feel free to change the canonical names themselves):

- sysutils/py-libioc (setup.py:name=libioc)
- sysutils/py-ioc (setup.py:name=ioc)

Alternatively:

- sysutils/py-libioc (setup.py:name=libioc)
- sysutils/py-ioc-cli (setup.py:name=ioc-cli)
Comment 5 gronke 2019-01-12 05:20:44 UTC
> Python ports should almost always be prefixed with PKGNAMEPREFIX=PYTHON_PKGNAMEPREFIX.

That is not required for this package because it is not an importable Python module.

> NO_BUILD=yes - replace with USE_PYTHON=distutils autoplist (variable is currently defined but empty incorrectly)

The variable is empty on purpose. Although this project uses Python (and has dependencies coming from Pip), it does not build a Python distribution. USE_PYTHON= is indeed wanted, but the fact that no files are written to PKGNAMEPREFIX makes it unnecessary to prefix this package with py36-*.

Otherwise users would be surprised that installing py36-ioc does not result in availability of the according module.

> The PORTNAME is not consistent with the setup.py:name (ioc_cli)

Before the rename of bug #234812 from devel/py-ioc to devel/py-libioc this CLI tool and the Python module had the same name. There is reason to use the Python module libioc without installing the CLI, which is only one client using the library.

The internal module name ioc_cli is only internally used to build the Click command structure.

> Use USE_RC_SUBR for the rc.d script, after copying the file from WRKSRC to files/ (FILESDIR) at post-extract: time. See: https://www.freebsd.org/doc/en/books/porters-handbook/book.html#rc-scripts

Thanks for the hint, will do!
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-01-12 05:57:16 UTC
(In reply to gronke from comment #5)

It's required for reasons of uniqueness of pkgname (distinct from the portname), because the port/package is build for a (any) particular python version, user-selectable, and will be invoked using that specific version and so for concurrent installation and conflicts (no conflicts between concurrently installable versions) reasons.

Said another way, when a python package supports multiple python versions (almost all of them), then concurrently installable versions should not conflict with each other. This means using a unique package name for the same port origin built with different python versions, and using USE_PYTHON=concurrent at least, and distutils/autoplist so that installed files are not in shared/common locations, causing conflicts.

If you don't want to prefix the 'portname' (and its svn dir) to be prefixed, that's fine, but I still would.

On the dependency front, one should depend on the respective python ports rather than install them via pip (or any other alternate mechanism), especially since the package already appears to declare its dependencies in the correct/appropriate way (*_requires/entry_points/et al). 

There are plenty of python packages that only provide console_scripts/scripts, not providing importable libraries, that use all of the standard distribution/installation mechanics that the python ecosystem offers and recommends. These all end up living in the version specific python environment even if the only normal way of accessing functionality is via LOCALBASE/bin scripts.
Comment 7 gronke 2019-01-12 09:17:35 UTC
Created attachment 201053 [details]
sysutils/ioc ports package

new release v0.5.0, portlint and poudriere QA
Comment 8 gronke 2019-02-08 20:51:36 UTC
Created attachment 201854 [details]
sysutils/ioc ports package

Update to ioc v0.6.0