I installed a package via pycharm earlier. I made some changes to the package's source code but found that pycharm would still run the old version, and I discovered that pycharm was actually running the cpython compiled .so version instead generated from the old code. Is there a way to force pycharm to rerun cpython or just interpret the source code instead? I tried removing all the cpython .so files but that causes the pycharm to segfault, so I suppose some of those cpython files are actually needed.
Python: how to edit an installed package?
You really shouldn't be editing these packages directly, it can easily become a headache down the road. I would recommend following the advice in the above link if you really feel like you need to edit the package, because it keeps you from, well, breaking things.
Related
I installed Python 3.5 from source and broke a number of modules on Python 3.4, which unfortunately, was an essential part of Ubuntu. I've been trying to fix the system, now I'm almost there, with (hopefully) the last problem: My Python 3.4 only recognize C modules with name *.cpython-34m.so, while all packages from Ubuntu repository are named *.cpython-34m-x86_64-linux-gnu.so. It seems that the cpython-34m stuff is the full name of Python, so I need to change it in accord with Ubuntu's expectation. How can I achieve this?
What you are trying makes no sense. The name cannot be changed, for a good reason. The reason the names are different is to prevent incompatible versions from mixing up each other. You can compile a different version with different options and then the name will be different, too.
The essence of the package management is to satisfy all dependencies through the repositories. Theoretically there should be no need to install anything from the sources.
If you need a different Python version for some specifical reasons, virtual environments would be the thing to look for:
http://docs.python-guide.org/en/latest/dev/virtualenvs/
I reinstalled Python 3.4 via Ubuntu package system, and suddenly everything worked fine. I still have no clue how Ubuntu customize its own Python, since Python's configure command has no related option at all. Anyway, it works, so why bother :P. Finally, thank you for helping me with this problem.
As described in: http://bugs.python.org/issue22139, the python27.dll is installed in the windows systems (in my case C:\Windows\Systems32) folder.
But I would like to know why? Why is it not installed next to the python.exe, for example in C:\Python27\?
Reason I ask: I've made a mercurial hook in python that our developers need to use to check if the commit message is valid. It checks a.o. for a valid JIRA issue number. To prevent all our developers to install python themselves and install the required modules manually (a lot of work and errorprone), I zipped the python installation and asked the developers to unzip it locally. But they can't run it, because the python27.dll is missing, or worse, they already have another minor version of python installed, and the hook will fail due to the wrong python27.dll used. Confusing.
If I just add the python27.dll (the correct version) to the zip file, it all seems to work great. So, why is it not installed in that location in the first place? What is the advantage of installing it in C:\Windows\System32?
Hope someone can explain this to me!
Thanks in advance,
Tallandtree.
I use the Anaconda Python distribution from http://continuum.io. They put python27.dll into c:\anaconda right next to its python.exe. This distribution is also superior in that you can have multiple python environments with precisely the packages you need and switch between them easily (http://conda.pydata.org/docs/using/envs.html). You can also get the package list of one of your environments and distribute it to others.
I recommend this Python distribution over the one from python.org and Enthought, because of this issue.
.dlls are quite windows-specific files. I imagine you will have shared object (.so) files for LINUX/UNIX-specific Python stuff? You said your developer's couldn't run it, because they didn't have the correct DLL (i.e. the one relevant to their Python installation).
Also, the advantage of installing it to System32 is that it's in the default PATH. Additionally, if any other application is internally using Python and require access to the .dll file, and also NOT reference your Python directory, they will probably be looking for a location that "Actually" exists (I wanted to say guaranteed to exist, but......never mind). That location would be `C:/windows/Systems32'.
I found it to work just fine to put python27.dll in the Python directory (c:\Python27 or wherever). As long as it's in the PATH, it seems to work. I did this for a "relocatable" installation of Python. I can copy the installation directory to a Windows machine that has no Python installed, set the PATH to include that directory, and run Python, including all the libraries I had installed with pip install on the original machine.
I'd like to install the pypoker-eval package. The author provided a nice readme for how to install the package in windows:
pypoker-eval on Windows
install python
open visual studio project and change directories to include python directories and fix the path to the poker-eval project
build the project, there may be an undefined ssize you can typedef as int
locate the newly built dll pypokereval.dll then look at the exports and you will find something similar to init_pokereval_2_4
rename the dll to _pokereval_2_4.pyd (your version numbers) and move it into the test.py directory
edit the .py files so the imported module is _pokereval_2_4 (your version numbers) not a dynamically generated one
To be quite honest though, these instructions really lost me. I've tried doing some research on my own, and I understand that because the library has some C code I need to compile it first. I wasn't able to figure out though what the purpose of changing the directories to include python directories, does this part mean change the working directory? Also is the compiler I use important? I've dabbled some in C but that was with the Code::Blocks IDE.
I think my main problem is I don't really understand what happens when I install a package. Pip has spoiled me and kept this whole process as a block box and now with something like this I feel completely lost. Any recommended reading on installing packages with C dependencies or tips on how I can get this package installed would be much appreciated!
For reference I'm using Python 2.7 on Windows 7.
I am writing a program in python to be sent to other people, who are running the same python version, however these some 3rd party modules that need to be installed to use it.
Is there a way to compile into a .pyc (I only say pyc because its a python compiled file) that has the all the dependant modules inside it as well?
So they can run the programme without needing to install the modules separately?
Edit:
Sorry if it wasnt clear, but I am aware of things such as cx_freeze etc but what im trying to is just a single python file.
So they can just type "python myapp.py" and then it will run. No installation of anything. As if all the module codes are in my .py file.
If you are on python 2.3 or later and your dependencies are pure python:
If you don't want to go the setuptools or distutiles routes, you can provide a zip file with the pycs for your code and all of its dependencies. You will have to do a little work to make any complex pathing inside the zip file available (if the dependencies are just lying around at the root of the zip this is not necessary. Then just add the zip location to your path and it should work just as if the dependencies files has been installed.
If your dependencies include .pyds or other binary dependencies you'll probably have to fall back on distutils.
You can simply include .pyc files for the libraries required, but no - .pyc cannot work as a container for multiple files (unless you will collect all the source into one .py file and then compile it).
It sounds like what you're after is the ability for your end users to run one command, e.g. install my_custom_package_and_all_required_dependencies, and have it assemble everything it needs.
This is a perfect use case for distutils, with which you can make manifests for your own code that link out to external dependencies. If your 3rd party modules are available publicly in a standard format (they should be, and if they're not, it's pretty easy to package them yourself), then this approach has the benefit of allowing you to very easily change what versions of 3rd party libraries your code runs against (see this section of the above linked doc). If you're dead set on packaging others' code with your own, you can always include the required files in the .egg you create with distutils.
Two options:
build a package that will install the dependencies for them (I don't recommend this if the only dependencies are python packages that are installed with pip)
Use virtual environments. You use an existing python on their system but python modules are installed into the virtualenv.
or I suppose you could just punt, and create a shell script that installs them, and tell them to run it once before they run your stuff.
In continuing to research a solution for this question on ServerFault:
https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows
I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:
More Info:
I am running Windows 7 64-bit
Both the TortoiseHG and the Mercurial directories are on my path, with the Mercurial directory listed first.
I have Python 2.6 installed in c:\Python26
I have no entry for any type of PYTHON-based environmental variable. (Should I?)
I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.
I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.
It seems to me that "there should only be one" Python on my machine. How do I achieve that?
For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python
As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.
Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".
Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").
I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.
I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.
I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.
See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx
Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.
Is something not working that prompted you to worry about this??
Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.
The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.
All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.