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.
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)
Created attachment 200980 [details] sysutils/ioc ports package
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.
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)
> 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!
(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.
Created attachment 201053 [details] sysutils/ioc ports package new release v0.5.0, portlint and poudriere QA
Created attachment 201854 [details] sysutils/ioc ports package Update to ioc v0.6.0
Created attachment 203669 [details] ioc Release v0.8.0
> 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. There is no need to install multiple versions on the same host. The build target is always the distributions default Python 3 version. > 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. Users of the ioc CLI tool do not care what language it is written in - they want to install it and use it to manage their jails. I don't find it necessary to require users knowing their target Python version, if we could instead depend on the same environment that we cover with our automated tests. > If you don't want to prefix the 'portname' (and its svn dir) to be prefixed, that's fine, but I still would. The language this is written in does not have an effect on the use of this CLI tool. If a tool written in RUST imports libioc and provides the same interfaces, there would be no noticeable difference for the user. Therefore I prefer to call it just ioc. > On the dependency front, one should depend on the respective python ports rather than install them via pip (or any other alternate mechanism) done
Created attachment 206420 [details] ioc Release v0.8.2
A commit references this bug: Author: swills Date: Mon Sep 2 15:00:57 UTC 2019 New revision: 510801 URL: https://svnweb.freebsd.org/changeset/ports/510801 Log: sysutils/ioc: create port Jail management CLI using libioc (compatible with iocage/iocell) WWW: https://github.com/bsdci/ioc PR: 234816 Submitted by: gronke <stefan@gronke.net> Changes: head/sysutils/ioc/ head/sysutils/ioc/Makefile head/sysutils/ioc/distinfo head/sysutils/ioc/files/ head/sysutils/ioc/files/ioc.in head/sysutils/ioc/pkg-descr head/sysutils/ioc/pkg-plist
Committed, thanks!