# mix of py38 & py39



## Alain De Vos (Jul 11, 2022)

When i look into my installed packages using poudriere if have an ugly mux of py38 & py39 packages.
Altough i have in blacklist,

```
lang/python2
lang/python27
lang/python36
lang/python37
lang/python38
#lang/python39
```

And in make.conf:

```
DEFAULT_VERSIONS+=python3=3.9
DEFAULT_VERSIONS+=python=3.9
```

How can this be explained


----------



## driesm (Jul 11, 2022)

I think the problem is flavored python ports. You'll have to manually update those. As an example if you have py38-speedtest-cli installed as leaf port, you'll have to "pkg install py39-speedtest-cli". This will remove the py38 version and install the py39 version.

Could you maybe share "pkg leaf | grep py38" that should only result in leaf ports and dependencies of those leaf ports. After updating to the py39 versions, you can "pkg autoremove" to get rid of the old dependencies.


----------



## suntzu00 (Jul 11, 2022)

keep in mind that some ports can't be built with >= python 3.9. for example security/py-certbot


----------



## driesm (Jul 12, 2022)

That is also correct. But certbot is not a correct example. There is nothing in the Makefile preventing use of python3.9. I think freshports is just not up-to date yet.


----------



## SirDice (Jul 12, 2022)

/usr/ports/UPDATING:

```
20220626:
  AFFECTS: users of python
  AUTHOR: thierry@FreeBSD.org

  The default version of python3 and python was switched to 3.9.

  For ports users wanting to keep version 3.8 as default,
  add DEFAULT_VERSIONS+= python=3.8 python3=3.8 to make.conf

  Following procedures may ease the upgrade:

  For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py38-*'); do pkg set -yn ${i}:py39-${i#py38-}; done
  # pkg upgrade

  For portmaster users:
  # sh
  # portmaster -o lang/python39 python38
  # REINSTALL="$(pkg info -o "*py38*" | awk '{printf "%s ", $2}')"
  # pkg delete -f "*py38*"
  # portmaster $REINSTALL
  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py39 | cut -d : -f 1 | sort -u)
  # portmaster $REBUILD
  # REBUILD2=$(pkg list | grep python-38 | xargs pkg which | awk '{print $6}' | sort -u)
  # portmaster $REBUILD2

  Final steps (for pre-built packages & portmaster):

  If no longer required, Python 3.8 can be removed via
  "pkg remove python38" and the directory /usr/local/lib/python3.8 can
  then be deleted afterwards, if not empty.
```


----------



## Alain De Vos (Jul 12, 2022)

But what if you use poudriere ?


----------



## SirDice (Jul 12, 2022)

Alain De Vos said:


> But what if you use poudriere ?




```
For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py38-*'); do pkg set -yn ${i}:py39-${i#py38-}; done
  # pkg upgrade
```

Also check poudriere-pkgclean(8).


----------



## Alain De Vos (Jul 12, 2022)

Thanks,
I can't ignore the impression that,

```
DEFAULT_VERSIONS+=python3=3.9
DEFAULT_VERSIONS+=python=3.9
```
is not really taking into account when building alot of packages, as if it still DEFAULTS to py38 as dependencies.


----------



## SirDice (Jul 12, 2022)

Well, that would be weird because Python 3.9 is the default now anyway. So even if your DEFAULT_VERSIONS is somehow ignored it would still use Python 3.9 as the default. But it's possible some ports actually have a hard set version dependency. A port could use `USES= python:3.8` for example, which would force the dependency on 3.8, regardless of what you've set as default. The default is used whenever a port uses Python without specifically requesting a certain version. 









						Chapter 17. Using USES Macros
					

USES macros make it easy to declare requirements and settings for a FreeBSD Port




					docs.freebsd.org


----------



## sko (Jul 12, 2022)

on most of my systems that use a local (poudriere-built) packages in combination with the official repos, python3.8 was removed by `pkg autoremove` after the first `pkg upgrade` that introduced the python3.9-dependant package versions.

In one jail I still have 3.8 installled as something still depends on it, but haven't found the time to investigate further. My best guess: the "problem" will resolve itself when ports get patched to just use the new default python (3.9 for now), so as long as everything works as expected and no important packages are removed due to conflicts, I wouldn't care too much about having both versions installed durnig a brief transition period.

At least you can (mostly) have both python versions installed without conflicts - with PHP you are forced to build everything you need against 7.4 if you want to use something that still doesn't support PHP8 (e.g. the Zabbix5 LTS-branch!)


----------



## Alain De Vos (Jul 12, 2022)

I did a "poudriere pkgclean -n -A -j ap -p ports | grep py38" & removed those. Now everything is on py39.


----------



## SirDice (Jul 12, 2022)

sko said:


> e.g. the Zabbix5 LTS-branch!)


The Zabbix frontend ports actually have a hard dependency on 7.4 now. So even with PHP set to 8.0 as default it will still build for 7.4. Those ports are actually the exceptions. I have a few other web ports that don't work with 8.x but they're still configured to use the default and do not have a hard version requirement. 

net-mgmt/zabbix5-frontend:

```
IGNORE_WITH_PHP=        80 81 82
```
This forces it to build the 7.4 flavor exclusively. Even if DEFAULT_VERSIONS sets PHP to 8.x. 

But www/webtrees20 for example simply builds with any PHP version that's set as default:

```
USES=		cpe php shebangfix zip
```
The actual webtrees code however doesn't work with PHP 8.0, it only supports up to 7.4.


----------



## Alain De Vos (Jul 12, 2022)

zabbix6 on the other hand seems to have a php80 frontend.


----------



## SirDice (Jul 12, 2022)

Alain De Vos said:


> zabbix6 on the other hand seems to have a php80 frontend.


Yes, it should be compatible with 8.0 and 8.1 now. Earlier 6.x versions weren't.


----------



## sko (Jul 12, 2022)

SirDice said:


> The Zabbix frontend ports actually have a hard dependency on 7.4 now. So even with PHP set to 8.0 as default it will still build for 7.4.



Good to know, thanks. 
I've set "DEFAULT_VERSIONS+=php=74" anyways, so I won't have to deal with multiple PHP versions. We also use horde groupware, which still blows up on multiple ends with PHP 8.0, so I'll stick with 7.4 for now until this has been fully solved and/or 7.4 is EOL.


----------

