Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Learning Python with the Natural Language Toolkit has been great fun, and they work fine on my local machine, though I had to install several packages in order to use it. Exactly how the NLTK resources are now integrated on my system remains a mystery to me, though it seems clear that the NLTK source code is not simply sitting someplace where the Python interpreter knows to find it.
I would like to use the Toolkit on my website, which is hosted by another company. Simply uploading the NLTK source code files to my server and telling scripts in the root directory to "import nltk" has not worked; I kind of doubted it would.
What, then, is the difference between whatever the NLTK install routine does and straightforward imports, and why should the toolkit be inaccessible to straightforward imports? Is there a way to use the NLTK source files without essentially altering my host's Python?
Many thanks for your thoughts and notes.
-G
Not only do you need NLTK on your PYTHONPATH (as #dhg points out), you need whatever dependencies it has; a quick local test indicates that this is really only PyYAML. You should just use pip to install packages. It's much less error-prone than trying to manually figure out all the dependencies and tweak the PYTHONPATH accordingly. If this is a shared host where you don't have the proper access to run a pip install, you should ask the host to do it for you.
To address the more general "Whatever the install script is doing" portion of your question: most Python packages are managed using setup.py, which is built on top of distutils (and sometimes setuputils). If this is something you're really interested in, check out The Hitchhiker’s Guide to Packaging.
You don't need system-install support, just the right modules where python can find them. I've set up the NLTK without system install rights with relatively little trouble--but I did have commandline access so I could see what I was doing.
To get this working, you should put together a local install on a computer you do control-- ideally one that never had NLTK installed, since you may have forgotten (or not know) what was configured for you. Once you figure out what you need, copy the bundle to the hosting computer. But at that point, check that you're using the module versions that are appropriate for the webserver's architecture. Numpy in particular has different 32/64 bit versions, IIRC.
It's also worth your while to figure out how to see the error messages from the hosting computer. If you can't see them by default, you could catch ImportError and display the message it contains, or you could redirect stderr... it depends on your configuration.
Let's assume that you have the NLTK source located in /some/dir/, so that
dhg /some/dir/$ ls nltk
...
app
book.py
ccg
chat
chunk
classify
...
You can either launch the python interpreter from the directory in which the nltk source directory is found:
dhg /some/dir/$ python
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34)
>>> import nltk
Or you can add its location to the PYTHONPATH environment variable, which makes NLTK available from anywhere:
dhg /whatever/$ export PYTHONPATH="$PYTHONPATH:/some/dir/"
dhg /whatever/$ python
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34)
>>> import nltk
Any other dependencies, including those that NLTK depends on, can also be added to the PYTHONPATH in the same way.
Related
I'm new to using python modules.
I'm currently working on a python 2.7 script that will be deployed to many remote computers (which have python 2.7 on them). The problem is that the script needs to use a module, which I am not allowed to install on those computers.
I'm wondering if it is possible to include the module files in the same package as my script (possibly have them compiled first), and then have the script import the library from that local folder, thus achieving a "portable" script.
If that is possible, how would I go about doing that?
Specifics: I'm running 2.7.11 on Windows needing to use Paramiko.
I'm asking this question because the similar questions that I can find either do not answer mine, or expect me to be familiar with core python structures with which I am not. I also DON'T want to include the entirety of python and then install the module onto that, something I see is often called Portable Python. I just want to send my script and the module and nothing more.
Many thanks!
To install modules in a specific directory, you can try pip install module --target=.
By default python search for those modules in same directory as the script first, then, if not available, it will search for python install lib files.
I want to implement a new model language for spaCY.
I have installed spaCy (using the guide of the official web site) on my Windows SO but I haven't understand where and how I could write and run my future files.
Help me, Thanks.
I hope I understand your question correctly: If you only want to use spaCy, you can simply create a Python file, import spacy and run it.
However, if you want to add things to the spaCy source – for example to add new language data that doesn't yet exist – you need to compile spaCy from source. On Windows, this needs a little more preparation – but it's not that difficult:
Install the Visual C++ Build Tools, which include the compiler you need.
Fork and clone the spaCy repository on GitHub.
Navigate to that directory and install spaCy's dependencies (other packages plus developer requirements like Cython) by running pip install -r requirements.txt.
Then run python setup.py build_ext --inplace from the same directory. This will build and compile spaCy into the directory.
Make sure your PYTHONPATH is set to the new spaCy directory. This is important so Python knows that you want to execute this exact version of spaCy, and not some other one you have installed somewhere else. On Windows, I normally use this command: set PYTHONPATH=C:\path\to\spacy\directory. There's also this thread with more info. (I'm no Windows expert, though – so if anyone reads this and disagrees, feel free to correct me here.)
You can now edit the source, add files and run them. If you want to add a new language, I'd recommend starting by adding a new directory to spacy/lang and creating an __init__.py. You can find more info on how this should look in the usage guide on adding languages.
To test if everything works, start the Python interpreter and import and initialise your language. For example, let's assume you've added Icelandic. You should then be able to do this:
from spacy.lang.is import Icelandic
nlp = Icelandic()
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Basically we have a Python library with modules and functions that we use in many of our programs. Currently, we checkout the SVN repository directly into C:\Python27\Lib so that the library is in the Python path. When someone make modifications to the library, everyone will update to get those modifications.
Some of our programs are frozen (using cx-Freeze) and delivered so we have to keep tracking of the library version used in the deliveries, but cx-Freeze automatically packages the modules imported in the code.
I don't think it is a good idea to rely on people to verify that they have no uncommitted local changes in the library or that they are up to date before freezing any program importing it.
The only version tracking we have is the commit number of the library repository, which is not linked anywhere to the program delivery version, and which should not be used as a delivery version of the library in my opinion.
I was thinking about using a setup.py to build a distribution of a specific version of that library and then indicate that version in a requirements.txt file in the project folder of the program importing it, but then it becomes complicated if we want to make modifications to that library because we would have to build and install a distribution each time we want to test it. It is not that complicated but I think someone will freeze a program with a test version of that library and it comes back to the beginning...
I kept looking for a best practice for that specific case but I found nothing, any ideas?
Ultimately you're going to have to trust your users to follow what development process you establish. You can create tools to make that easier, but you'll always end up having some trust.
Things that have been helpful to a number of people include:
All frozen/shipped builds of an executable are built on a central machine by something like BuildBot or Jenkins, not by individual developers. That gives you a central point for making sure that builds are shipped from clean checkouts.
Provide scripts that do the build and error out if there are uncommitted changes.
Where possible it is valuable to make it possible to point PYTHONPATH at your distribution's source tree and have things work even if there is a setup.py that can build the distribution. That makes tests easier. As always, make sure that your tools for building shipped versions check for this and fail if it happens.
I don't personally think that a distribution has a lot of value over a clean tagged subversion checkout for a library included in closed-source applications.
You can take either approach, but I think you will find that the key is in having good automation for whichever approach you choose, not in the answer to distribution vs subversion checkout
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I am an amateur and have a mac and I would like to reset all python. I want to delete all the versions other than the one already on the mac in the OS. I would like the python versions to be as if I had just gotten a new OS.
THanks!!!
Unfortunately, there is no one-size-fits all answer here, because there are a number of different ways to install Python, many of which do not come with uninstallers.
Everything Apple installs is inside /System, or inside /usr but not /usr/local. So, those are the areas not to touch, no matter what.
Apple's Pythons put their system-wide site packages in /Library/Python/X.Y. Some third-party Pythons may also use site packages there. If you've mixed and matched, there's no way to straighten that up except to wipe the whole thing. To restore these directories to a clean slate, each one should have nothing but a site-packages directory, in which there should be nothing but a README and a easy-install.pth and/or Extras.pth.
Some third-party packages that have binary installers meant to work with Apple's Python install things into /usr/local/lib/pythonX.Y/site-packages. Again, these are shared with other Python installations. If you want to restore to a clean slate, delete everything in any such directory.
If you've configured user-specific site packages, or virtual environments, you should know which ones go with which Python—and, if you don't, just scrap them entirely.
Apple's Pythons install or link any scripts/executables that come with any site packages into /usr/local/bin. Unfortunately, most third-party Pythons will do the same thing. And of course non-Python executables installed from elsewhere also end up here. The only way to really be safe is to only delete files here that:
Are symlinks to something in /Library/Frameworks/Python.framework or into a site-packages directory.
Are scripts whose shebang lines points to a non-Apple Python (that is, it's not in /System or /usr/bin).
Are executables that link to a non-Apple Python (visible with otool -L).
If you're also trying to kill site packages installed into Apple Python, symlinks, shebangs, and executable links that point to Apple Python can go too.
Anything installed with a package manager—Homebrew, MacPorts, Fink, etc.—should be uninstalled the same way: brew uninstall python, sudo port uninstall python3.2, etc.
Anything that has an uninstaller (either inside a Python X.Y or MacPython or similar folder in Applications, or on the original disk image), obviously run that.
Meanwhile, non-Apple standard framework builds—that is, any binary installer from python.org, or anything you build yourself according to simple instructions—will put files into the following places:
/Library/Framework/Python.framework/X.Y. This is the main guts. Kill it. In fact, kill the whole Python.framework to remove all versions at once.
/usr/local/bin, shared with Apple, as mentioned above.
/usr/local/lib. Anything named libpython* here is killable.
/Applications/[Mac]Python*.
Non-framework builds by default install everything into /usr/local; they will be effectively the same as framework builds, but with no /Library/Framework/Python.framework/X.Y, and instead a /usr/local/lib/pythonX.Y that contains things besides just site-packages. Kill those things.
Third-party installations like Enthought or (x,y), you will have to figure out what you have and find the uninstallation instructions on their site. There's really no way around that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm novice in this, and I have started learning Python, but I have some questions that I'm not be able to understand,
What exactly is the PYTHONPATH (on Ubuntu)? Is it a folder?
Is Python provided by default on Ubuntu, or does it have to be installed explicitly?
Where is the folder in which all modules are (I have a lot folders called python_)?
If I wish a new module to work when I'm programming (such as pyopengl) where should I go to introduce all the folders I've got in the folder downloaded?
Coming back from the PYTHONPATH issue, how do I configure the PYTHONPATH in order to start working on my new module?
PYTHONPATH is an environment variable which you can set to add additional directories where python will look for modules and packages. e.g.:
# make python look in the foo subdirectory of your home directory for
# modules and packages
export PYTHONPATH=${PYTHONPATH}:${HOME}/foo
Here I use the sh syntax. For other shells (e.g. csh,tcsh), the syntax would be slightly different. To make it permanent, set the variable in your shell's init file (usually ~/.bashrc).
Ubuntu comes with python already installed. There may be reasons for installing other (independent) python versions, but I've found that to be rarely necessary.
The folder where your modules live is dependent on PYTHONPATH and where the directories were set up when python was installed. For the most part, the installed stuff you shouldn't care about where it lives -- Python knows where it is and it can find the modules. Sort of like issuing the command ls -- where does ls live? /usr/bin? /bin? 99% of the time, you don't need to care -- Just use ls and be happy that it lives somewhere on your PATH so the shell can find it.
I'm not sure I understand the question. 3rd party modules usually come with install instructions. If you follow the instructions, python should be able to find the module and you shouldn't have to care about where it got installed.
Configure PYTHONPATH to include the directory where your module resides and python will be able to find your module.
PYTHONPATH is an environment variable
Yes (see https://unix.stackexchange.com/questions/24802/on-which-unix-distributions-is-python-installed-as-part-of-the-default-install)
/usr/lib/python2.7 on Ubuntu
you shouldn't install packages manually. Instead, use pip. When a package isn't in pip, it usually has a setuptools setup script which will install the package into the proper location (see point 3).
if you use pip or setuptools, then you don't need to set PYTHONPATH explicitly
If you look at the instructions for pyopengl, you'll see that they are consistent with points 4 and 5.
PYTHONPATH is an environment variable those content is added to the sys.path where Python looks for modules. You can set it to whatever you like.
However, do not mess with PYTHONPATH. More often than not, you are doing it wrong and it will only bring you trouble in the long run. For example, virtual environments could do strange things…
I would suggest you learned how to package a Python module properly, maybe using this easy setup. If you are especially lazy, you could use cookiecutter to do all the hard work for you.