Re: Can we have multiple flavors for a port?
Le 16/12/2017 à 14:51, Matthew Seaman a écrit : > Given that django-2.0 requires python-3.5+ we end up with the following > combinations: > >py27 django111 >py36 django111 >py36 django20 So you have: FLAVORS= py27_django111 py36_django111 py36_django20 and if BUILD_ALL_PYTHON_FLAVORS is set, you'll need to add py34_django111, py35_django111, py35_django20, but this can be done automatically. > and there's some 104 django ports which will mostly end up needing all > three of these variants built -- so as combinatorial explosions go, it's > not particularly earth-shattering. > > However, my questions are: > > - Is it possible or desirable to have multiple flavourings like this? > > - If so, what should the syntax look like for specifying a particular > combination? eg. www/py-django-mezzanine@py27+django111 ? > > Cheers, > > Matthew > > -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: Can we have multiple flavors for a port?
Le 16/12/2017 à 15:24, Stefan Esser a écrit : > The answer I received was very clear: There can only be 1 flavor per port > and there are no plans to remove that restriction. You missed the part where I said that there would only be 2 or 3 flavors, maybe 4 in some extreme cases per port. No more. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: Can we have multiple flavors for a port?
On 16/12/2017 14:24, Stefan Esser wrote: > Am 16.12.17 um 14:51 schrieb Matthew Seaman: >> >> I have a review up to add a USES=django -- >> https://reviews.freebsd.org/D12592 which I'm now modifying to be FLAVORS >> compatible given that has hit the tree. >> >> Now, we currently have ports for 4 different versions of django (1.8, >> 1.10, 1.11, 2.0) and the obvious next move is to add django-based >> flavouring. Currently, most django ports depend on django-1.8, with a >> few depending on django-1.10, but this I think is mostly due to inertia >> and django ports should be compatible with more recent versions. Having >> four different versions of django in ports seems excessive -- so, for >> the sake of argument I'd cut that down to just django-1.11 and django-2.0 >> >> But this is all python code, and the python flavouring would also apply... >> >> Given that django-2.0 requires python-3.5+ we end up with the following >> combinations: >> >>py27 django111 >>py36 django111 >>py36 django20 >> >> and there's some 104 django ports which will mostly end up needing all >> three of these variants built -- so as combinatorial explosions go, it's >> not particularly earth-shattering. >> >> However, my questions are: >> >> - Is it possible or desirable to have multiple flavourings like this? >> >> - If so, what should the syntax look like for specifying a particular >> combination? eg. www/py-django-mezzanine@py27+django111 ? > > I asked portmgr@ the same question when I started to work on portmaster > and did not want to implement a solution that does only support a single > flavor per port (or rather, waste time and effort on a portmaster version > that only supported 1 flavor per port, when there were plans to support > multiple flavors in the ports framework in the future). > > The answer I received was very clear: There can only be 1 flavor per port > and there are no plans to remove that restriction. > > I questioned the wise-ness of that decision, but had better use for my > time than to continue arguing, that multi-flavor support was probably > going to be required very soon. > > > My questions were specifically, how a dependency with multiple flavors > should be specified (e.g. "@py36@xyz") and how to query a port for this > case. The same notation should be used in the MOVED file in such a case. > > The order of flavors added to an origin must either be ignored by all > tools operating on them (which precludes simple string comparisons to > see whether one origin+flavors is identical to another one) or should > be required to follow some (e.g.) lexical order. > > > I'd also like to see the flavor(s) (if any) become part of the port origin > (or some other variable in the PKG DB that can easily be queried). The > value should be identical to the format in dependencies and the MOVED > file to simplify tools like portmaster, which currently must execute a > complex series of queries to get at that information. Heh. I wrote the package annotation functionality, but I never anticipated the way that it has come to be used. I just thought of it as a way for package builders and end users to add notes to their package database, with no real functional effect. Instead, now it's being used as the quick and simple way to add novel metadata to packages, and to affect the way pkg(8) goes about solving dependency chains. I have some mixed feelings about this. We used to have significant database schema churn whenever some metadata change happened in pkg(8), which made upgrading pkg(8) a bit more risky and harder to back-out than ideal. Now though, you can just create an annotation. No low-level schema change needed. On the other hand, you can't use pkg-query(8) or pkg-rquery(8) or similar to select and display packages according to the new metadata items like flavor. > The origin@flavor does not encode the information previously contained > in just the origin. > > > IMHO, multi-flavor support should have been one of the initial considerations > when designing the flavor extension to the ports system! Hmmm... There is another consideration here. Most of the django stuff I'm looking at is pure python code, and not dependent on against linkage to any specific shared library. Which means that the packages for the different flavours would be basically identical except for the metadata tracking the dependency chain. Making a raft of such similar packages, replicating the package file content each time strikes me as wasteful of time and resources. Why can't we express the alternate possibilities in the package metadata and have one package that fits all cases? I recall a proposal about "variable dependencies" being discussed at BSDCan a few years back -- is this anywhere on the roadmap? Potentially this would apply to many of the packages for interpreted or byte-compiled languages in the tree -- so Perl, Ruby, PHP, Java and in principle Python, although that has been complicated
Re: Can we have multiple flavors for a port?
Am 16.12.17 um 14:51 schrieb Matthew Seaman: > > I have a review up to add a USES=django -- > https://reviews.freebsd.org/D12592 which I'm now modifying to be FLAVORS > compatible given that has hit the tree. > > Now, we currently have ports for 4 different versions of django (1.8, > 1.10, 1.11, 2.0) and the obvious next move is to add django-based > flavouring. Currently, most django ports depend on django-1.8, with a > few depending on django-1.10, but this I think is mostly due to inertia > and django ports should be compatible with more recent versions. Having > four different versions of django in ports seems excessive -- so, for > the sake of argument I'd cut that down to just django-1.11 and django-2.0 > > But this is all python code, and the python flavouring would also apply... > > Given that django-2.0 requires python-3.5+ we end up with the following > combinations: > >py27 django111 >py36 django111 >py36 django20 > > and there's some 104 django ports which will mostly end up needing all > three of these variants built -- so as combinatorial explosions go, it's > not particularly earth-shattering. > > However, my questions are: > > - Is it possible or desirable to have multiple flavourings like this? > > - If so, what should the syntax look like for specifying a particular > combination? eg. www/py-django-mezzanine@py27+django111 ? I asked portmgr@ the same question when I started to work on portmaster and did not want to implement a solution that does only support a single flavor per port (or rather, waste time and effort on a portmaster version that only supported 1 flavor per port, when there were plans to support multiple flavors in the ports framework in the future). The answer I received was very clear: There can only be 1 flavor per port and there are no plans to remove that restriction. I questioned the wise-ness of that decision, but had better use for my time than to continue arguing, that multi-flavor support was probably going to be required very soon. My questions were specifically, how a dependency with multiple flavors should be specified (e.g. "@py36@xyz") and how to query a port for this case. The same notation should be used in the MOVED file in such a case. The order of flavors added to an origin must either be ignored by all tools operating on them (which precludes simple string comparisons to see whether one origin+flavors is identical to another one) or should be required to follow some (e.g.) lexical order. I'd also like to see the flavor(s) (if any) become part of the port origin (or some other variable in the PKG DB that can easily be queried). The value should be identical to the format in dependencies and the MOVED file to simplify tools like portmaster, which currently must execute a complex series of queries to get at that information. The origin@flavor does not encode the information previously contained in just the origin. IMHO, multi-flavor support should have been one of the initial considerations when designing the flavor extension to the ports system! Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Can we have multiple flavors for a port?
I have a review up to add a USES=django -- https://reviews.freebsd.org/D12592 which I'm now modifying to be FLAVORS compatible given that has hit the tree. Now, we currently have ports for 4 different versions of django (1.8, 1.10, 1.11, 2.0) and the obvious next move is to add django-based flavouring. Currently, most django ports depend on django-1.8, with a few depending on django-1.10, but this I think is mostly due to inertia and django ports should be compatible with more recent versions. Having four different versions of django in ports seems excessive -- so, for the sake of argument I'd cut that down to just django-1.11 and django-2.0 But this is all python code, and the python flavouring would also apply... Given that django-2.0 requires python-3.5+ we end up with the following combinations: py27 django111 py36 django111 py36 django20 and there's some 104 django ports which will mostly end up needing all three of these variants built -- so as combinatorial explosions go, it's not particularly earth-shattering. However, my questions are: - Is it possible or desirable to have multiple flavourings like this? - If so, what should the syntax look like for specifying a particular combination? eg. www/py-django-mezzanine@py27+django111 ? Cheers, Matthew signature.asc Description: OpenPGP digital signature
