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

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

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
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"

Reply via email to