Bug 226634

Summary: devel/py-setuptools: pkg-static: py27-setuptools-38.5.2 conflicts with py36-setuptools-38.5.2 (installs files into the same place). Problematic file: /usr/local/bin/easy_install
Product: Ports & Packages Reporter: Helmut Ritter <freebsd-ports>
Component: Individual Port(s)Assignee: freebsd-python mailing list <python>
Status: Closed Works As Intended    
Severity: Affects Only Me CC: chrysalis, hiroo.ono+freebsd, koobs, skh1002
Priority: --- Flags: bugzilla: maintainer-feedback? (python)
Version: Latest   
Hardware: Any   
OS: Any   

Description Helmut Ritter 2018-03-15 17:14:50 UTC
Duplicity requires Python27 but the default is Python36 on FreeBSD 11.1. Unfortunately Python27 and Python36 cannot exist in parallel:

pkg-static: py27-setuptools-38.5.2 conflicts with py36-setuptools-38.5.2 (installs files into the same place).  Problematic file: /usr/local/bin/easy_install
Comment 1 Serge 2018-05-28 19:16:49 UTC
Until today and the update to the latest py-setuptools 39.2.0, I had no problem keeping both py27 and py36 flavours installed, but today I ran into the exact same problem concerning update from 39.0.1 to 39.2.0:

[Ports.local] Installing py36-setuptools-39.2.0...
pkg-static: py36-setuptools-39.2.0 conflicts with py27-setuptools-39.0.1 (installs files into the same place).  Problematic file: /usr/local/bin/easy_install
*** Error code 70

Obviously, something broke the build since previously I was always able to build and use both py27-setuptools and py36-setuptools at the same time.
Comment 2 Serge 2018-05-28 19:35:15 UTC
I stand corrected. I thought I had both py27 and py36 flavours of py-setuptools installed, but in fact, I had py36-setuptools_scm, not py36-setuptools. Therefore, it looks like, according to the original post, the two flavours cannot be installed at the same time.

This is a huge bummer, because I use samba47, which depends on py27-setuptools, and now I am not able to update anything depending on python36 since the majority of these ports require py36-setuptools now.
Comment 3 Antoine Brodin freebsd_committer 2018-05-28 19:44:56 UTC
How did you install py27-setuptools and py36-setuptools_scm ?

Did you play with default versions on the command line (you should not) ?

I have py27-setuptools py36-setuptools_scm and samba47 on the same host without any issue.
Comment 4 Serge 2018-05-28 19:53:03 UTC
Hi Antoine,

Thanks for replying. I am not sure how I ended up with py36-setuptools_scm because right now nothing depends on it. It must have been installed because of something else that I removed since. I deleted it now. The py27-setuptools must have been installed automatically when I installed samba47.

I did not play with default versions on the command line (I use portmaster with a few pretty harmless flags), but I did have to add the following to /etc/make.conf:

DEFAULT_VERSIONS+= python3=3.6
DEFAULT_VERSIONS+= python=3.6

When installing py-iocage. Otherwise, it would not build.
Comment 5 Serge 2018-05-28 19:55:46 UTC
Sorry for spamming. It is py36-setuptools that is incompatible with py27-setuptools, not py36-setuptools_scm. My problem is that I cannot have 

py36-setuptools + py27-setuptools

at the same time.
Comment 6 Antoine Brodin freebsd_committer 2018-05-28 20:00:05 UTC
(In reply to Serge from comment #4)
So you installed samba47 and py27-setuptools with an empty make.conf (hence DEFAULT_VERSIONS=python=2.7) and later installed py36-iocage with make.conf having DEFAULT_VERSIONS=python=3.6 ?

I think this is not supported, DEFAULT_VERSIONS should be constant on 1 host.
Comment 7 Serge 2018-05-28 21:04:39 UTC
First of all, a clarification. It is py36-setuptools that is incompatible with py27-setuptools, not py36-setuptools_scm. My problem is that I cannot have 

py36-setuptools + py27-setuptools

at the same time.

Now, you may be right that changing DEFAULT_VERSIONS is not supported, but in this particular case, samba47 explicitly depends on py27 flavour of py-setuptools. Just to double-check, I rebuilt it with DEFAULT_VERSIONS+= python=3.6, but it did not change anything.

Therefore, regardless of support, there is a dilemma: if I set DEFAULT_VERSIONS+= python=2.7, I am unable to build py-iocage, because it explicitly depends on py36; and if I set it to 3.6, samba47 will still pull in py27-setuptools because it explicitly depends on 2.7. If I had something depending on py36-setuptools before, I would not have been able to build samba47. 

So, one way or another this still comes to py27-setuptools being apparently incompatible with py36-setuptools.
Comment 8 Serge 2018-05-29 22:18:37 UTC
Hi Antoine,

I have been trying to understand what is going on, and it looks like I was able to clear things up. I am putting it here in case someone else runs into this problem.

It turns out, that you were actually right about changing DEFAULT_VERSIONS. What happened is py27-setuptools were built on my system with DEFAULT_VERSIONS=python=2.7 and then I set it to DEFAULT_VERSIONS+= python=3.6. So the problem was in the way py27-setuptools was built. When I manually removed it and rebuilt with DEFAULT_VERSIONS+= python=3.6, it became possible to have both py27 and py36 flavours at the same time.

So, you have set me on the right track and I think the flavour system works as intended.

Thank you.
Comment 9 Antoine Brodin freebsd_committer 2019-01-04 09:51:54 UTC
Conclusion was "the flavour system works as intended"
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2019-03-28 09:51:28 UTC
Elaborating/extending Serge's comment "So the problem was in the way py27-setuptools was built", to benefit others that have reported, or find themselves with, similar issues

How the port was built was one of the 'causes', but it is not 'the problem' (as it is indeed 'intended')

The other cause is changing the default version after having installed things with a different default version.

These two things together create the failure case.

The reason is, the 'way' a *default* version of a python port gets built *is* different than a *non-default* version, in particular for script names (LOCALBASE/bin/*). For example:

A default version port will install:

LOCALBASE/bin/foo, *AND*
LOCALBASE/bin/foo-X.Y

A non-default version port will *ONLY* install:

LOCALBASE/bin/foo-X.Y

The reason is, only ONE port can have the 'LOCALBASE/bin/foo' (version-less) name, and that one port is the *current* 'default version'.

Default version can either be set by the user, or the default (set in Mk/python.mk)

Now if a user has a system where 2.7 'was' the default (which is every new user to freebsd, at present), they'll have the following files installed:

easy_install
easy_install-2.7

Then they switch to 3.6 (3.6 now the default)

Something wants to install setuptools, 3.6 is now the default version, so it goes to install:

easy_install
easy_install-3.6

easy_install already exists, boom, we have a conflict.
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2019-03-28 09:55:38 UTC
(In reply to Kubilay Kocak from comment #10)

The above applies to *any* port/package that installs a file with a filename *shared* between multiple versions (FLAVORs) of that port, not just setuptools
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2019-03-30 04:03:06 UTC
*** Bug 236843 has been marked as a duplicate of this bug. ***
Comment 13 Chris Collins 2019-07-14 00:20:21 UTC
Kubilay thanks for the explanation, but how did you fix it step by step?
Comment 14 Chris Collins 2019-07-14 00:30:04 UTC
I have the following set (not recently changed)

python=2.7 python2=2.7 python3=3.6

my easy-install is correctly linked to 2.7 binary

This is whats installed

# pkg info | grep setuptools
py27-setuptools-41.0.1         Python packages installer
py27-setuptools_scm-3.3.3      Setuptools plugin to manage your versions by scm tags
py36-setuptools-40.8.0         Python packages installer

portupgrade spits this out

--->  Upgrade of devel/py-setuptools started at: Sun, 14 Jul 2019 01:25:26 +0100
--->  Upgrading 'py36-setuptools-40.8.0' to 'py27-setuptools-41.0.1' (devel/py-setuptools)

which suggests something is broken, based upon Kubilay's explanation I should be good, my master binary is symlinked to the correct version, it would appear even tho its not the default the 3.6 version is trying to install a binary as the default version ignoring the make.conf variable.

Are we sure its due to a duplicated binary, as I dont get the message about installing files to same place instead I just get an "error 70".

Also this is spitted out also.

Message from py36-setuptools-40.8.0:

*******************************************************************

  Only /usr/local/bin/easy_install-3.6 script has been installed
  since Python 3.6 is not the default Python version.

*******************************************************************

So in terms of default files, that side of things looks correct.

full error below 

"The operation will free 4 MiB.
[1/1] Deinstalling py36-setuptools-40.8.0...
[1/1] Deleting files for py36-setuptools-40.8.0: 100%
[Reading data from pkg(8) ... - 608 packages found - done]
--->  Uninstallation of py36-setuptools-40.8.0 ended at: Sun, 14 Jul 2019 01:28:05 +0100 (consumed 00:00:02)
--->  Installation of devel/py-setuptools started at: Sun, 14 Jul 2019 01:28:05 +0100
--->  Installing the new version via the port
===>  Installing for py27-setuptools-41.0.1
===>   Registering installation for py27-setuptools-41.0.1
*** Error code 70

Stop.
make[1]: stopped in /usr/ports/devel/py-setuptools
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/py-setuptools
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20190714-37535-1hsm3uv env UPGRADE_TOOL=portupgrade UPGRADE_PORT=py36-setuptools-40.8.0 UPGRADE_PORT_VER=40.8.0 make reinstall
--->  Updating dependency info
--->  Restoring the old version
Installing py36-setuptools-40.8.0...
Extracting py36-setuptools-40.8.0: 100%
Message from py36-setuptools-40.8.0:

*******************************************************************

  Only /usr/local/bin/easy_install-3.6 script has been installed
  since Python 3.6 is not the default Python version.

*******************************************************************
--->  Removing old package'
** Fix the installation problem and try again."