I'm using the svn-python bindings (libsvn) to power Trac on Windows.
Previous to the Tigris->Apache migration of Subversion, I was able to download the Python bindings (svn-python-*.exe) here:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11151&expandFolder=11151&folderID=260
What happened to those bindings under the new regime?
I think they're maintained externally, like at http://sourceforge.net/projects/win32svn/files/1.6.15/.
Yup:
The Apache Subversion project does not
officially endorse or maintain any
binary packages of the Subversion
software. However, volunteers have
created binary packages for different
distributions and platforms, and as a
convenience, we maintain a list of
links to them here.
The URL above is the only listed as having bindings at http://subversion.apache.org/packages.html#windows.
I needed these today. You can get the 1.6.6 source from Tigris and there is a path "packages\python-windows" which contains a readme and setup.py file. Combine those with the bindings from win32svn 1.6.15 and you can try to generate an installer.
However, it didn't fully work for me. I am getting errors (running mailer.py) saying that there is an error importing module _core (libsvn_core.dll as far as I can see). Not sure why, might be my system, maybe it will work for you.
Related
I am trying to install GeoDjango what turns out to be much harder than I thought. After I installed the OSGeo4W on my 64 Bit Windows 10 system I set everything up in the settings.py file but now I get this error:
FileNotFoundError: Could not find module 'C:\OSGeo4W\bin\gdal304.dll' (or one of its dependencies). Try using the full path with constructor syntax.
I also set the GDAL_LIBRARY_PATH but it just won't work.
GDAL_LIBRARY_PATH = "C:\\OSGeo4W\\bin\\gdal304.dll"
This is my C:\OSGeo4W\bin path and as you can see the gdal304.dll file is there
My Python is on version 3.10.6
Django is on version 4.1
I already tried to solve it by myself for a week but slowly I have no idea left on what to do
I ran into this problem too, since I updated my old GEO Django Setup today.
You may use a Docker Image as suggested by the others, but I prefere a native solution, since I don't want to spin up Docker every time I start coding.
Your solution is in the brackets: (or one of its dependencies)
You may look up the transitive dependendencies from gdal304.dll. There are several tools for this (see here). I'm using here now the Git integrated MinGW - Shell that has ldd installed. This should be the case for any (newer) Git installation on Windows.
As you can see, some dependencies are already fullfilled from your operating system. Others that are missing, have to be fullfilled from OSGeo4W. If you compare this with your bin directory from OSGeo4W you will see the Problem:
Sadly a simple "renaming" does not the trick. I was lucky and had not yet deleted my old OSGeo4W version. In the old files I then found the necessary DLL.
So, long story short: You need the jpeg.dll file.
There are sites like "windll.com" or "dll-files.com", but I would not recommend using them. I don't trust these sites. You may install something like "MSYS2", "Cygwin" or even "MVSC", install the "libjpeg-turbo" library and then finally copy & paste the necessary DLL file.
This is also suggested on the official Site for libjpeg-turbo: https://libjpeg-turbo.org/Documentation/OfficialBinaries
But this seems like a lot of work for someone who just want to have the DLL file, but then again: Never download a library blindly from the Internet and load it into your application. These libraries could do anthing!
I'm in desperate need of a cross platform framework as I have vast numbers of .NET products that I'm trying to port to Linux. I have started to work with Python/pyQt and the standard library and all was going well until I try to import non-standard libraries. I'm hearing about pip and easy_install and I'm completely confused about this.
My products need to ship with everything required to execute them, so in the .NET world I simply package my DLLs (or licensed DLLs) with my product.
As a test bed I'm trying to import this library called requests: https://github.com/kennethreitz/requests
I've got an __init__.py file and the library source in my program directory but it isn't working. Please tell me that there is a simple way to include libraries without needing any kind of extra package installer.
I would suggest you start by familiarizing yourself with python packages (see the distutils docs. Pip is simply a manager that install packages directly from the internet repository, so that you don't need to manually go and download them. So for, example, as stated under "Installing" on the requests homepage, you simply run pip install requests in a terminal, without manually downloading anything.
Packaging your product is a different story, and the way you do it depends on the target system. On windows, the easiest might be to create an installer using NSIS which will install all dependencies. You might also want to use cx-freeze to pull all the dependencies (including the python interpreter) into a single package.
On linux, many of the dependencies will already be including in most distributions. so you should just list them as requirements when creating your package (e.g. deb for ubuntu). Other dependencies might not be included in the distro's repo, but you can still list them as requirements in setup.py.
I can't really comment on Mac, since I've never used python on one, but I think that it would be similar to the linux approach.
I have some small Python programs which depend on several big libraries, such as:
NumPy & SciPy
matplotlib
PyQt
OpenCV
PIL
I'd like to make it easier to install these programs for Windows users. Currently I have two options:
either create huge executable bundles with PyInstaller, py2exe or similar tool,
or write step-by-step manual installation instructions.
Executable bundles are way too big. I always feel like there is some magic happening, which may or may not work the next time I use a different library or a new library version. I dislike wasted space too. Manual installation is too easy to do wrong, there are too many steps: download this particular interpreter version, download numpy, scipy, pyqt, pil binaries, make sure they all are built for the same python version and the same platform, install one after another, download and unpack OpenCV, copy its .pyd file deep inside Python installation, setup environment variables and file asssociations... You see, few users will have the patience and self-confidence to do all this.
What I'd like to do: distribute only a small Python source and, probably, an installation script, which fetches and installs all the missing dependencies (correct versions, correct platform, installs them in the right order). That's a trivial task with any Linux package manager, but I just don't know which tools can accomplish it on Windows.
Are there simple tools which can generate Windows installers from a list of URLs of dependencies1?
1 As you may have noticed, most of the libraries I listed are not installable with pip/easy_install, but require to run their own installers and modify some files and environment variables.
npackd exists http://code.google.com/p/windows-package-manager/ It could be done through here or use distribute (python 3.x) or setuptools (python 2.x) with easy_install, possibly pip (don't know it's windows compatibility). But I would choose npackd because PyQt and it's unusual setup for pip/easy_install (doesn't play with them nicely, using a configure.py instead of setup.py). Though you would have to create your own repo for npackd to use for some of them. I forget what is contributed in total for python libs with it.
AFAIK there is no tool (and I'd assume you googled), so you must make one yourself.
Fetching the proper library versions seems simple enough -- using python's ftplib you can fetch the proper installers for every library. How would you know which version is compatible with the user's python? You can store different lists of download URLs, each for a different python version (this method came off the top of my head and there is probably a better way; not that it matters much if it's simple and it works).
After you figure out how to make each installer run, you can py2exe your installer script, and even use it to fetch the program itself.
EDIT
Some Considerations
There are a couple of things that popped into my mind just as I posted:
First, some pseudocode (how I would approach it, anyway)
#first, we check modules
try:
import numpy
except ImportError:
#flag numpy for installation
#lather, rinse repeat for all dependencies
#next we check version compatibility -- note that if a library version you need
#is not backwards-compatible, you're in DLL hell, and there is little we can do.
<insert version-checking code here>
#once you have your unavailable dependencies, you install them
import ftplib
<all your file-downloading here>
#now you install. sorry I can't help you here.
There are a few things you can do to make your utility reusable --
put all URL lists, minimum version numbers, required library names etc in config files
Write a script which helps you set up an installer
Py2exe the installer-maker-script
Sell it
Even better, release it under GPL so we can all feast upon fruits of your labours.
I have a similar need as you, but in addition I need the packaged application to work on several platforms. I'm currently exploring the currently available solutions, here are a few interesting ones:
Use SnakeBasket, which wraps around Pip and add a recursive dependency resolution plus a heuristic to choose the right version when there are conflicts.
Package all dependencies as an egg, but not your sourcecode which will still be editable: https://stackoverflow.com/a/528064/1121352
Package all dependencies in a zip file and directly import the modules on the fly: Cross-platform alternative to py2exe or http://davidf.sjsoft.com/mirrors/mcmillan-inc/install1.html
Using buildout: http://www.buildout.org/en/latest/install.html
Using virtualenv with virtualenv-tools (instead of "relocate")
If your main problem when freezing your code using PyInstaller or similar is that you end up with a big single file, you can customize the process so that you get several files, one for each dependency, instead of one big executable.
I will update here if I find something that fills my bill.
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.
I've written an app in python that depends on wxPython and some other python libraries. I know about pyexe for making python scripts executable on Windows, but what would be the easiest way to share this with my Mac using friends who wouldn't know how to install the required dependencies? One option would be to bundle my dependencies in the same package, but that seems kind of clunky. How do people usually deploy such apps? For once I miss Java...
You could check out py2app, which is similar to py2exe
How do people usually deploy such apps?
2 choices.
With instructions.
All bundled up.
You write simple instructions like this. Folks can follow these pretty reliably, unless they don't have enough privileges. Sometimes they need to sudo in linux environments.
Download easy_install (or pip)
easy_install this, easy_install that (or pip this, pip that)
easy_install whatever package you wrote.
It works really well. If you download some Python packages you'll see this in action.
Sphinx requires docutils. Django requires docutils and PIL. It works out really well to simply document the dependencies. Other folks seem to do it without serious problems. Follow their lead.
Bundling things up means you have to
(a) provide the entire original distribution (as required by most open source licenses)
(b) provide a compatible open source license with the licenses of the things you bundled. This can be easy if you depend on things that all of the same license. Otherwise, you basically can't redistribute them and have to resort to installation instructions.