Re: svn commit: r463374 - head/security/nyx
On 3/2/18 9:03 PM, Kubilay Kocak wrote: > > users care, that software someone does is not in question. ^W---^ > > ./koobs > ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 3/2/18 8:45 PM, Mathieu Arnold wrote: > On Fri, Mar 02, 2018 at 07:57:51AM +, Kubilay Kocak wrote: >> 1) Assuming what users care about is risky business. >> 2) The 'app vs library' distinction is not sound here. It wasn't sound >> for python package prefixing in the past either. >> 3) The change introduces and increases inconsistency among Python ports >> without an upside, without precluding downsides. > > The downside is more packages, and longer build times. Thus, it was > decided to not flavorize ports that do not provide modules. Posing the upside (for python/freebsd users) as a downside is odd. We signed up to resource utilisation when we decided we'd produce binary packages, and flavors. But that derailment aside, it's also a slippery slope. >> The bottom and most important line however, is that preventing Python >> port flavors from being produced precludes the user from choosing what >> version of the package they may want. > > The dozen people who will really, really want to have a cli supporting > more than one Python version with the non default version can probably > build it themselves. Python pushed for variants/flavors to support the flexibility and choice of python port consumers for a diverse annd complex ecosystem as well as to reduce maintenance/development overhead for port maintainers and the python team. All that is being said is that the special case is not special enough. #PEP20 >> lastly, the only reason the noflavors knob exists is because its not >> terribly pleasant as a developer to have features that cant be disabled, >> and because our framework can't imagine all the possible scenarios where >> a feature may cause issues. > > No, the noflavors knob was added after a failed experiment with the > optsuffix knob, to accomodate ports which do not need flavors, like big > applications that only needs python for small features, or cli that do > not really care which Python version is running them. This is a separate use-case (the exception for which was made for prefixing as well) users care, that software someone does is not in question. ./koobs ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 3/2/18 7:32 PM, Yuri wrote: > On 03/01/18 23:57, Kubilay Kocak wrote: >> 1) Assuming what users care about is risky business. > > > Port has to provide to users functionality that they expect. If port is > an app, executable provides this functionality. Executables based on > different python versions are expected to work the same way. If they In Python land, there is categorically no established expectation that 'apps' work identically between versions, nor do they actually in reality in the vast majority of cases, in particularly between major versions. Beyond that: 1. user sees software foo supports Python X - Y 2. user wants to use foo for Y, the stack for which they have already have installed (not X) 3. user cannot find said package 4. user is forced to install foo for X and foo's dependencies for X unnecessarily 1. user wants to migrate from X to Y 2. user wants to replace foo for X with foo for Y 3. user cannot do what they want > don't work the same way, this is a bug. Packages aren't created in order > to allow users to detect bugs, or to compare performance, therefore > there should be no need to build multiple packages for apps. If some But what if that's what users want to do? I know I and many others have. > expert user will want to test with some other python versions, he still > can do this by rebuilding it locally. This was the logic why I added Why should that be necessary? Why would we introduce that barrier? > noflavors. For libraries though functionality is a set of python > modules, therefore they should be in all flavors. What you suggest (to > have flavors for apps) just doesn't seem to have any benefit. :) POLA also applies. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On Fri, Mar 02, 2018 at 07:57:51AM +, Kubilay Kocak wrote: > 1) Assuming what users care about is risky business. > 2) The 'app vs library' distinction is not sound here. It wasn't sound > for python package prefixing in the past either. > 3) The change introduces and increases inconsistency among Python ports > without an upside, without precluding downsides. The downside is more packages, and longer build times. Thus, it was decided to not flavorize ports that do not provide modules. > The bottom and most important line however, is that preventing Python > port flavors from being produced precludes the user from choosing what > version of the package they may want. The dozen people who will really, really want to have a cli supporting more than one Python version with the non default version can probably build it themselves. > lastly, the only reason the noflavors knob exists is because its not > terribly pleasant as a developer to have features that cant be disabled, > and because our framework can't imagine all the possible scenarios where > a feature may cause issues. No, the noflavors knob was added after a failed experiment with the optsuffix knob, to accomodate ports which do not need flavors, like big applications that only needs python for small features, or cli that do not really care which Python version is running them. -- Mathieu Arnold signature.asc Description: PGP signature
Re: svn commit: r463374 - head/security/nyx
On 03/01/18 23:57, Kubilay Kocak wrote: 1) Assuming what users care about is risky business. Port has to provide to users functionality that they expect. If port is an app, executable provides this functionality. Executables based on different python versions are expected to work the same way. If they don't work the same way, this is a bug. Packages aren't created in order to allow users to detect bugs, or to compare performance, therefore there should be no need to build multiple packages for apps. If some expert user will want to test with some other python versions, he still can do this by rebuilding it locally. This was the logic why I added noflavors. For libraries though functionality is a set of python modules, therefore they should be in all flavors. What you suggest (to have flavors for apps) just doesn't seem to have any benefit. :) Yuri ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 3/2/18 6:40 PM, Yuri wrote: > If the port can only be used as an app, as opposed to library, multiple > flavors aren't needed. All users care about is an executable. It doesn't > matter what python version is used. That's what sane^Wyou and I would think. :-) On Fri, Mar 02, 2018 at 06:57:51PM +1100, Kubilay Kocak wrote: > 2) The 'app vs library' distinction is not sound here. It wasn't sound > for python package prefixing in the past either. It was always sound and meaningful, but FreeBSD Python cabal had decided otherwise (and adopted that stupid "prefix everything with py-" rule which is counterintuitive and makes looking for programs harder). But oh well, we've argued over this years ago Kubilay. ./danfe ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 3/2/18 6:40 PM, Yuri wrote: > On 03/01/18 23:23, Kubilay Kocak wrote: >> This reason doesn't sound correct. Could you explain this further? > > > If the port can only be used as an app, as opposed to library, multiple > flavors aren't needed. All users care about is an executable. It doesn't > matter what python version is used. 1) Assuming what users care about is risky business. 2) The 'app vs library' distinction is not sound here. It wasn't sound for python package prefixing in the past either. 3) The change introduces and increases inconsistency among Python ports without an upside, without precluding downsides. 4) It feels similar to the PORTVERSION/DISTVERSION changes being introduced. Just because you can, doesn't mean you should. The bottom and most important line however, is that preventing Python port flavors from being produced precludes the user from choosing what version of the package they may want. lastly, the only reason the noflavors knob exists is because its not terribly pleasant as a developer to have features that cant be disabled, and because our framework can't imagine all the possible scenarios where a feature may cause issues. This isn't one of those scenarios. Could you please revert that specific change in both security/py-obfsproxy-tor and security/nyx? > > Yuri > ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 03/01/18 23:23, Kubilay Kocak wrote: This reason doesn't sound correct. Could you explain this further? If the port can only be used as an app, as opposed to library, multiple flavors aren't needed. All users care about is an executable. It doesn't matter what python version is used. Yuri ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: svn commit: r463374 - head/security/nyx
On 3/2/18 5:51 PM, Yuri Victorovich wrote:
> Author: yuri
> Date: Fri Mar 2 06:51:55 2018
> New Revision: 463374
> URL: https://svnweb.freebsd.org/changeset/ports/463374
>
> Log:
> security/nyx: Add USE_PYTHON=noflavors; Add LICENSE_FILE
>
> nyx is an app, therefore noflavors.
This reason doesn't sound correct. Could you explain this further?
Context:
FLAVORS are for package building infrastructure to produce multiple
variations of the same underlying port, within the same repository/run,
in Pythons case, for multiple python versions (pyXY-foo).
Whether something is an 'app' or not (by some definition, though i'm
assuming it means 'end user program not library'), does not factor into
whether or not it has or needs flavors, just whether it supports
multiple versions.
Note: Whether or not a port has flavor's is orthogonal (in pythons case)
to whether or not said packages are, or desired to be by the user,
concurrently installable or not.
>
> Approved by:tcberner (mentor, implicit)
> Approved by:portmgr (port compliance, infrastructure)
>
> Modified:
> head/security/nyx/Makefile
>
> Modified: head/security/nyx/Makefile
> ==
> --- head/security/nyx/MakefileFri Mar 2 06:31:47 2018
> (r463373)
> +++ head/security/nyx/MakefileFri Mar 2 06:51:55 2018
> (r463374)
> @@ -12,12 +12,13 @@ MAINTAINER= c...@freebsd.org
> COMMENT= Command-line monitor for Tor
>
> LICENSE= GPLv3
> +LICENSE_FILE=${WRKSRC}/LICENSE
>
> -RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}stem>=1.6.0:security/py-stem@${FLAVOR} \
> - ${PYTHON_PKGNAMEPREFIX}sqlite3>0:databases/py-sqlite3@${FLAVOR}
> +RUN_DEPENDS=
> ${PYTHON_PKGNAMEPREFIX}stem>=1.6.0:security/py-stem@${PY_FLAVOR} \
> +
> ${PYTHON_PKGNAMEPREFIX}sqlite3>0:databases/py-sqlite3@${PY_FLAVOR}
>
> USES=python
> -USE_PYTHON= distutils autoplist
> +USE_PYTHON= distutils autoplist noflavors
> NO_ARCH= yes
>
> PLIST_FILES= man/man1/nyx.1.gz
>
___
freebsd-python@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
