Python frameworks

[Ryan Schmidt]

On Aug 9, 2011, at 01:31, Russell Jones wrote:

> From: Ryan Schmidt [ryandesign at macports.org]
> Sent: 08 August 2011 17:50
> To: Russell Jones
> Cc: mark brethen; macports-users at lists.macosforge.org
> Subject: Re: Python frameworks
> 
>> Are you suggesting that a port, such as py27-pylint, should install different contents (e.g. a pylint symlink, or not), depending on what python has been selected with "sudo port select python"? 
> 
> Yes.
> 
>> If so, I would be strongly against that. "port select" is exclusively for a user's convenience; no port should change how it installs or functions based on what the user may or may not have "port select"ed.
> 
> I can kind of see why you wouldn't want this on principle, but could you elaborate? Why should a user have to select which version of python they want for every package, when in the majority of cases the same version will be desired? Having a default doesn't exclude exceptions.

If the user prefers a particular version of python, the user should so indicate by adding that python variant to their variants.conf file.


> I guess the main problem would be the case where a user switches back and forth constantly between selections, making it a poor basis for variant selection.
> 
> If one port selects gcc-mp-4.5, say, doesn't that mean it will be used as the system gcc,

Yes, if by "system gcc" you mean "the program run when you type 'gcc'". Again, "port select" is for the benefit of the user's convenience when running programs on the command line; MacPorts itself and its port do not use or take notice of any of those selections*

(*shouldn't: some ports in fact do, and these are bugs that need to be fixed)


> and so to compile ports?

Absolutely not. Ports always build with a specific compiler, usually one based on the Xcode version installed, though some ports may override this and request a specific MacPorts gcc compiler instead. Usually these ports provide gcc variants then. Read the wiki page UsingTheRightCompiler for more on this.


> I can see that's undesirable (inconsistent packages, untested toolchains, etc)

Exactly, which is why we don't let the user change the compiler for most ports.


> On the other hand, if a user selected +as_python for a bunch of ports as a deliberate (and hopefully comprehended) action because they want to have only one place where they set the python version, I think such problems would be avoided.

No. It is not proper for a port to install itself differently based on what a user may have selected as their preferred python version today, since the user could easily change that preference tomorrow. In fact, unless the user has gone out of their way to actually select a python version, the default python version is Apple's, which would be unsuitable for use with any MacPorts-installed python module. Finally, remember that we are now building ports on our buildbot server and distributing binaries; we would not want a possibly selected version of python on the buildbot server to affect the contents of the port when delivered to the end user.