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"
