RE: Python frameworks
From: Ryan Schmidt [ryandes...@macports.org] Sent: 08 August 2011 17:50 To: Russell Jones Cc: mark brethen; macports-users@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 selected. 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. 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, and so to compile ports? I can see that's undesirable (inconsistent packages, untested toolchains, etc) 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. Russell ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 9, 2011, at 01:31, Russell Jones wrote: From: Ryan Schmidt [ryandes...@macports.org] Sent: 08 August 2011 17:50 To: Russell Jones Cc: mark brethen; macports-users@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 selected. 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. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
RE: Python frameworks
Thanks for the explanation. OK, so the key would seem to be consistently named variants (and possibly a list of python-related variants if more than one is needed) that can be set in variants.conf From: Ryan Schmidt [ryandes...@macports.org] Sent: 09 August 2011 07:43 To: Russell Jones Cc: mark brethen; macports-users@lists.macosforge.org Subject: Re: Python frameworks ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Tue, Aug 9, 2011 at 02:31, Russell Jones russell.jo...@physics.ox.ac.ukwrote: 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 selected. 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. When the user uses port select to change the default Python, what should happen to all of these? How do you plan to implement it? What if there isn't a version of something installed this way for the selected Python variant? -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
OK, here's how I understand it. Taking a look at 'spyder' in /opt/local/bin: Marks-MacBook-Pro:bin marbre$ more spyder #!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python from spyderlib import spyder spyder.main() And in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python, the Python 2.7.2 Launcher is run. Which explains why spyder will run Python 2.7 in its console regardless of what is in PATH. The 'programs.py' script seems to be where module existence is checked by spyder. This function is called by 'pylintgui.py' to check for pylint: def is_program_installed(basename, get_path=False): Return True if program is installed and present in PATH for path in os.environ[PATH].split(os.pathsep): abspath = osp.join(path, basename) if osp.isfile(abspath): if get_path: return abspath else: return True else: return False I also found this function: def is_module_installed(module_name): Return True if module *module_name* is installed try: __import__(module_name) return True except ImportError: return False I'm sure what calls this, but I would think it would stand a better chance of success in the MacPorts python framework. -Mark On Aug 8, 2011, at 5:43 PM, Brandon Allbery wrote: On Mon, Aug 8, 2011 at 12:48, Ryan Schmidt ryandes...@macports.org wrote: On Aug 6, 2011, at 11:20, mark brethen wrote: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. I understand the developer's viewpoint, but he is probably not aware of all of the complexities involving software packaging. We have multiple ports for spyder and pylint in MacPorts (for each of several versions of Python). These can be installed simultaneously, so they cannot install the same files. So none of these can install an executable /opt/local/bin/pylint. Strictly speaking, it's not a package manager issue, it's a configuration manager issue. This kind of thing comes up most often in managed environments using configuration managers such as Puppet, bcfg2, Chef, cfengine, etc., as well as university environments such as depot (CMU), Athena (MIT), and Nikola (UW); this is somewhat important for research professors and students working on their Ph.D theses who don't want to risk having to deal with path or version vagaries across platforms. The correct answer here is for spyder to use a global config file to get the default values for these settings, so that $configuration_manager_of_choice can configure the install in the local support tree to use programs from the local support tree. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
How about this? http://jessenoller.com/2009/03/16/so-you-want-to-use-python-on-the-mac/ -Mark On Aug 9, 2011, at 11:30 AM, Brandon Allbery wrote: On Tue, Aug 9, 2011 at 02:31, Russell Jones russell.jo...@physics.ox.ac.uk wrote: 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 selected. 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. When the user uses port select to change the default Python, what should happen to all of these? How do you plan to implement it? What if there isn't a version of something installed this way for the selected Python variant? -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
RE: Python frameworks
Or simpler for the user (perhaps) have an as_python option, the default (this would work for ipython, too), which would set the value based on the selected version of python, e.g. python2.7 - pylint-2.7 (or however it's written in the port select names) Russell ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 6, 2011, at 11:20, mark brethen wrote: Would it be best to create a 'pylint' group and use port select? This would reflect the developer's viewpoint: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. Of course this would make sense to differentiate pylint executable for Python 2 and Python 3. So the purist in me would tend to say that when pylint is properly installed, the command 'pylint' should work in a terminal. I understand the developer's viewpoint, but he is probably not aware of all of the complexities involving software packaging. We have multiple ports for spyder and pylint in MacPorts (for each of several versions of Python). These can be installed simultaneously, so they cannot install the same files. So none of these can install an executable /opt/local/bin/pylint. We could certainly entertain the idea of making the py*lint ports use the select portgroup, which you've requested here: https://trac.macports.org/ticket/30626 That would help users run pylint by that name, but it is not a solution for other software (like spyder) that wants to run pylint, for reasons explained in Joshua's comments in that ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 8, 2011, at 11:43, Russell Jones wrote: Or simpler for the user (perhaps) have an as_python option, the default (this would work for ipython, too), which would set the value based on the selected version of python, e.g. python2.7 - pylint-2.7 (or however it's written in the port select names) I don't understand this as_python suggestion. 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? 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 selected. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
With python27 port installed, and a reverse-engineered local portfile of py26-spyder, I was able to get spyder 2.0.12 running. I do not have multiple python frameworks installed on my mac. If I run python in a terminal window it uses: Mark-Brethens-MacBook-Pro:bin marbre$ python Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. Which is installed by the mac os. However, when I run spyder, it shows in its console: Python 2.7.2 (default, Aug 5 2011, 19:07:44) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type copyright, credits or license for more information. /opt/local/bin contains 'python2.7', which is a symbolic link of the same name as the binary it links to. Spyder's pylint widget searches PATH for 'pylint' but I have 'pylint-2.7' in /opt/local/bin, which is a symbolic link; it does not have the same name as the binary it links to. Spyder recognizes IPython even though the symlink in /opt/local/bin has a different name. I don't have an explanation for this. -Mark On Aug 8, 2011, at 11:48 AM, Ryan Schmidt wrote: On Aug 6, 2011, at 11:20, mark brethen wrote: Would it be best to create a 'pylint' group and use port select? This would reflect the developer's viewpoint: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. Of course this would make sense to differentiate pylint executable for Python 2 and Python 3. So the purist in me would tend to say that when pylint is properly installed, the command 'pylint' should work in a terminal. I understand the developer's viewpoint, but he is probably not aware of all of the complexities involving software packaging. We have multiple ports for spyder and pylint in MacPorts (for each of several versions of Python). These can be installed simultaneously, so they cannot install the same files. So none of these can install an executable /opt/local/bin/pylint. We could certainly entertain the idea of making the py*lint ports use the select portgroup, which you've requested here: https://trac.macports.org/ticket/30626 That would help users run pylint by that name, but it is not a solution for other software (like spyder) that wants to run pylint, for reasons explained in Joshua's comments in that ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
Would it be best to create a 'pylint' group and use port select? This would reflect the developer's viewpoint: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. Of course this would make sense to differentiate pylint executable for Python 2 and Python 3. So the purist in me would tend to say that when pylint is properly installed, the command 'pylint' should work in a terminal. -Mark On Aug 1, 2011, at 8:46 PM, Ryan Schmidt wrote: On Aug 1, 2011, at 18:15, mark brethen wrote: On Aug 1, 2011, at 11:55 AM, Daniel J. Luke wrote: On Jul 30, 2011, at 12:00 AM, mark brethen wrote: I'm confused how the python frameworks work. For instance, I should be able to type 'pylint script.py' in a command window, but the command isn't found. So I looked in /opt/local/bin and found 'pylint-2.7' which is a symbolic link to '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. Spyder displays Please install pylint in the PyLint Panel, which I suspect is because it can't find pylint. How do you set your environment so that programs like Spyder find python binaries? The pylint port should probably provide links to the stuff that should be available (like the trac port does). I would recommend that you open a ticket in the issue tracker to get it fixed. There is no pylint port. There are: $ port echo name:py.*lint py-lint py25-lint py26-lint py27-lint As such, none of these ports can claim /opt/local/bin/pylint. That is why there is a suffix on each binary. This is not a bug. Any port using this software needs to refer to it by the correct suffixed name. I did some digging in the spyder script that checks for the existence of pylint. It looks to me that spyder checks for the binary in the User's path. This will return false since a symbolic-link to pylint, named 'pylint-2.7' is installed in '/opt/local/bin'; pylint being installed into '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. As a test, I created another symbolic link 'pylint' that points to 'pylint-2.7' and as expected, was able to use the pylint widget in spyder. It seems to me, a better way to test for its existence would use PYTHONPATH. Great, so it's a bug in the py*-spyder port(s) for not looking for pylint by its correct MacPorts name. Please file a ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Jul 30, 2011, at 12:00 AM, mark brethen wrote: I'm confused how the python frameworks work. For instance, I should be able to type 'pylint script.py' in a command window, but the command isn't found. So I looked in /opt/local/bin and found 'pylint-2.7' which is a symbolic link to '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. Spyder displays Please install pylint in the PyLint Panel, which I suspect is because it can't find pylint. How do you set your environment so that programs like Spyder find python binaries? The pylint port should probably provide links to the stuff that should be available (like the trac port does). I would recommend that you open a ticket in the issue tracker to get it fixed. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
I did some digging in the spyder script that checks for the existence of pylint. It looks to me that spyder checks for the binary in the User's path. This will return false since a symbolic-link to pylint, named 'pylint-2.7' is installed in '/opt/local/bin'; pylint being installed into '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. As a test, I created another symbolic link 'pylint' that points to 'pylint-2.7' and as expected, was able to use the pylint widget in spyder. It seems to me, a better way to test for its existence would use PYTHONPATH. -Mark On Aug 1, 2011, at 11:55 AM, Daniel J. Luke wrote: On Jul 30, 2011, at 12:00 AM, mark brethen wrote: I'm confused how the python frameworks work. For instance, I should be able to type 'pylint script.py' in a command window, but the command isn't found. So I looked in /opt/local/bin and found 'pylint-2.7' which is a symbolic link to '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. Spyder displays Please install pylint in the PyLint Panel, which I suspect is because it can't find pylint. How do you set your environment so that programs like Spyder find python binaries? The pylint port should probably provide links to the stuff that should be available (like the trac port does). I would recommend that you open a ticket in the issue tracker to get it fixed. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 1, 2011, at 18:15, mark brethen wrote: On Aug 1, 2011, at 11:55 AM, Daniel J. Luke wrote: On Jul 30, 2011, at 12:00 AM, mark brethen wrote: I'm confused how the python frameworks work. For instance, I should be able to type 'pylint script.py' in a command window, but the command isn't found. So I looked in /opt/local/bin and found 'pylint-2.7' which is a symbolic link to '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. Spyder displays Please install pylint in the PyLint Panel, which I suspect is because it can't find pylint. How do you set your environment so that programs like Spyder find python binaries? The pylint port should probably provide links to the stuff that should be available (like the trac port does). I would recommend that you open a ticket in the issue tracker to get it fixed. There is no pylint port. There are: $ port echo name:py.*lint py-lint py25-lint py26-lint py27-lint As such, none of these ports can claim /opt/local/bin/pylint. That is why there is a suffix on each binary. This is not a bug. Any port using this software needs to refer to it by the correct suffixed name. I did some digging in the spyder script that checks for the existence of pylint. It looks to me that spyder checks for the binary in the User's path. This will return false since a symbolic-link to pylint, named 'pylint-2.7' is installed in '/opt/local/bin'; pylint being installed into '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pylint'. As a test, I created another symbolic link 'pylint' that points to 'pylint-2.7' and as expected, was able to use the pylint widget in spyder. It seems to me, a better way to test for its existence would use PYTHONPATH. Great, so it's a bug in the py*-spyder port(s) for not looking for pylint by its correct MacPorts name. Please file a ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
