Where is python.exe in a Windows tarball installation? - python

After installing Python 3.5.6 using a tarball (.gz file), I would like to run
C:\path\to\desired\venv\directory>c:\path\to\python\installation\Python-3.5.6\python -m venv venv
However, my Python-3.5.6 directory doesn't seem to include the necessary python.exe. After extracting Python from a tarball on Windows, what extra steps are required to produce the python executable?
Note: I already have Python 3.6 installed as the default.

That's not a "tarball installation". You downloaded the source code and extracted it manually into somewhere you shouldn't. This is roughly analogous to attempting to live in the blueprints of a house.
If for some reason you are determined to use 3.5.6, you will have to find an actual installer somewhere (there is no official one), or you will have to build it yourself. From PCbuild/readme.txt:
Quick Start Guide
Install Microsoft Visual Studio 2015, any edition.
Install Subversion, and make sure 'svn.exe' is on your PATH.
Run "build.bat -e" to build Python in 32-bit Release configuration.
(Optional, but recommended) Run the test suite with "rt.bat -q".
For more complete build instructions, see PCbuild/readme.txt.

Related

Installing rpm module for (non-system) Python

I need to support some software that is using an old Python version (2.4). So I have downloaded and compiled Python 2.4 and installed it in a virtualenv. So far, all OK and normal procedure.
But the software is trying to import an rpm module. And I cannot find a source for that module (it is not part of the standard Python library, afaict).
Typically, once the virtualenv is enabled (source env/bin/activate) I can install required software using easy_install. But easy_install rpm is failing to find anything. There is a pyrpm module, but it is not the same thing (it installs a module called "pyrpm"). And google searches are useless, as they all link to articles on how to build rpms...
If I were using the system python (on Ubuntu) I could install the python-rpm package. But that is for Python 2.7. How do I install the equivalent for Python 2.4?
[My impression is that the rpm libraries, used by many Linux systems, include a Python library, which is packaged as python-dev by the distro. But I can't see how to access that for an arbitrary python version.]
I AM NOT LOOKING FOR AN RPM THAT CONTAINS PYTHON 2.4. I AM LOOKING FOR A MODULE NAMED rpm THAT IS USED BY SOFTWARE WRITTEN FOR PYTHON 2.4.
It's right there, in the python-rpm RPM package:
http://rpmfind.net/linux/rpm2html/search.php?query=python-rpm
You will probably want to download the package contents, extract them, and then use
python setup.py install
From your active environment.
Of course, as it's pre compiled, you might have trouble getting the C extension to run.
I'm not familiar enough with RPM's to know whether you can get the source from there.
No guarantees the package will work with your python version though.
there's no simple way to do this; the python library is part of the system rpm package and interfaces to C code, so is closely tied to the rpm package installed on your machine.
instead, it's much simpler to install an old OS in a VM (eg CentOS 5) that uses Python 2.4. then everything is consistent and works.
the sources for the rpm module can be found here: http://www.rpm.org/wiki/Download
After you download the wanted version read and follow the INSTALL instructions in order to compile it on your target OS. Afterwards make sure you add the correct path to the 'site-packages' folder the installation chose into your PYTHONPATH environment variable.
To test start your python interpreter and run 'import rpm'
HTH,
Ran

How to install Python in Linux without previous version installed

I'm currently doing some embedded systems programming. This was set up by somebody else a few years ago. So now I'm looking to upgrade to Python 2.7.2 to make things simpler because I have already run into two cases where what I coded wasn't supported.
What is currently running:
: uname -a
Linux host1 2.6.18-6-486 #1 Sun Feb 10 22:06:33 UTC 2008 i586 GNU/Linux
: python -v
Python 2.4.4
: pyversions -i
python2.4
So right now only 2.4 is installed.
I untarred python2.7.2 and when I go to that directory and run python27 setup.py install --home=/home/jhemilian and it seems like python2.4 doesn't seem to know the with...as statement syntax:
host1:/home/jhemilian/src/Python-2.7.2: python setup.py install --home=/home/jhe
milian
File "setup.py", line 361
with open(tmpfile) as fp:
^
SyntaxError: invalid syntax
Before I go figuring this out I first have a question: python itself is being used to install Python? What if I didn't have the first version of Python installed? I know it's shipped with most Linux but hypothetically -- how does such a seeming catch-22 like that work?
What I am looking to do is install python2.7 in a benign location, keeping the python command still as using Python 2.4 just in case the "legacy" software i'm running is dependent on it, and running python2.7 myscript.py et cetera when I want to run one of my newer scripts. Feel free to comment if there is a cleaner or more practical (or even safer!) way to do this.
I don't think it would make much sense to go replacing all the with statements with compatible try blocks. I've looked though the READMEs and online documentation but I can't seem to find a way to install Python without already having Python. Note that I DO NOT have internet connection, although if desirable or necessary I could. It would be great if somebody could point me in the right direction. Thanks!!
It's all right in the README...
You don't need to use python to install, in fact, you shouldn't...just:
./configure
make
make install
If you want to install in a specific dir, just follow what the README says:
Installing
To install the Python binary, library modules, shared library modules
(see below), include files, configuration files, and the manual page,
just type
make install
This will install all platform-independent files in subdirectories of
the directory given with the --prefix option to configure or to the
prefix' Make variable (default /usr/local). All binary and other
platform-specific files will be installed in subdirectories if the
directory given by --exec-prefix or theexec_prefix' Make variable
(defaults to the --prefix directory) is given.
If DESTDIR is set, it will be taken as the root directory of the
installation, and files will be installed into $(DESTDIR)$(prefix),
$(DESTDIR)$(exec_prefix), etc.
All subdirectories created will have Python's version number in their
name, e.g. the library modules are installed in
"/usr/local/lib/python/" by default, where is the
. release number (e.g. "2.1"). The Python binary is
installed as "python" and a hard link named "python" is
created. The only file not installed with a version number in its
name is the manual page, installed as "/usr/local/man/man1/python.1"
by default.
If you want to install multiple versions of Python see the section
below entitled "Installing multiple versions".
The only thing you may have to install manually is the Python mode for
Emacs found in Misc/python-mode.el. (But then again, more recent
versions of Emacs may already have it.) Follow the instructions that
came with Emacs for installation of site-specific files.
EDIT: virtualenv is apparently for already-installed Python versions. Disregard this recommendation.
I think what you want is virtualenv.
I haven't used it myself, but I understand this is what it's meant for.
From the website:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
EDIT: Upon review, I think you want Alberto's answer, so I voted him up for visibility.

I am installing python 3 on snow leopard, what am I installing exactly?

I'm having difficulty installing python 3 on snow leopard.
I'm having difficulty because I have no idea what I am installing. (I do understand that python is a language, and that it uses a virtual machine)
Where can I get an overview of all the parts that make up working installation of python and how they need to be configured?
I want to understand this so that I can use python 3, but not break the other installations on my system.
There is normally no need to build Python on Mac OS X from source. If you want the most recent Python 3, download and install one of the two official Python 3.2 installers for OS X from python.org here. The Python installers from python.org install a framework build of Python 3 rooted at
/Library/Frameworks/Python.framework/Versions/3.2
In that directory, you will find bin, lib, and other directories unique to that version. If you install another Python versions (say, 2.7) using python.org installers, it will be be installed under /Library/Frameworks/Python.framework/Versions/2.7, completely independent of the 3.2 version. There will also be a version of IDLE.app and other files installed into /Applications/Python m.n (3.2, 2.7, etc.). The Apple-supplied system Pythons (2.6.1 and 2.5.4 for OS X 10.6) are installed in:
/System/Library/Frameworks/Python.framework/Versions/
again a completely separate location. Thus, the system Python files do not need to be and should not be altered or removed. The python.org installers have the option to alter your shell PATH variable to prepend the appropriate framework bin directory to your path so that the newly installed Python will be found first. With Python 3 there is no conflict anyway, since you need to invoke it by python3, rather than python.
The python.org installers also have the option to install symlinks from /usr/local/bin to the important files in the framework bin directory but, for various reasons, those are not particularly useful. In general, you need to include the framework bin directory in your execution PATH; with that, the /usr/local/bin symlinks are usually not needed.
If you are really interested in the details, download the source tarball and examine configure.in and the top level makefile. The script that is used to build the installer is in Mac/BuildInstaller.
For additional information about Python on Mac OS X and the use of Tkinter, IDLE, and Tcl/Tk, see this page.
Go to Python.org
Download the source
Unpack
Follow the steps in the README (see below)
It will install to python3 by default thereby not breaking your other distros.
On Unix, Linux, BSD, OSX, and Cygwin:
./configure
make
make test
sudo make install
This will install Python as python3.
You can pass many options to the configure script; run "./configure --help" to
find out more. On OSX and Cygwin, the executable is called python.exe;
elsewhere it's just python.
On Mac OS X, if you have configured Python with --enable-framework, you should
use "make frameworkinstall" to do the installation. Note that this installs the
Python executable in a place that is not normally on your PATH, you may want to
set up a symlink in /usr/local/bin.
On Windows, see PCbuild/readme.txt.
If you wish, you can create a subdirectory and invoke configure from there. For
example:
mkdir debug
cd debug
../configure --with-pydebug
make
make test
(This will fail if you also built at the top-level directory. You should do a
"make clean" at the toplevel first.)
--
You are installing packages and modules. You can download the source and look through the directory. Everything installed is as it appears. This is not Windows where files are spewed everywhere on the system.

Installing Trac with Subversion 1.6

I'm trying to set up Trac on my server and have successfully installed it, compiled the bytecode and run the tracd server. The only problem is that it's not reading my SVN repository.
The error I'm receiving is:
Warning: Can't synchronize with the repository (Couldn't open Subversion repository /data1/repos: SubversionException: ("Expected FS format '2'; found format '4'", 160043)). Look in the Trac log for more information.
(Yes, my single repository is in a folder called "repos" - I didn't set that bit up)
The trac.ini looks like this:
repository_dir = /data1/repos
repository_type = svn
I'm running: Trac 0.11.5, Python 2.4.3, Collabnet SVN 1.6.5, SWIG 1.3.29
Is your python svn library updated? Sounds like it's stale.
you should make sure the python binding match your SVN version.
to get the binding you can use the SVN source and compile the wrapper, the install give an overview of the process how to build that binding.
first you would have to download the svn source
BUILDING SWIG BINDINGS FOR SVN ON UNIX
after build the swig binding
Step 1: Install a suitable version of
SWIG (which is
currently swig version 1.3.24 - 1.3.31).
* Perhaps your distribution packages a suitable version - if it
does
install it, and skip to the last bullet point in this section.
* Go to http://www.swig.org/, download the source tarball, and
unpack.
* In the SWIG-1.3.xx directory, run ./configure.
If you plan to build the Python bindings, and have a system
with more than one version of Python installed, you may need
to pass
--with-python=/path/to/correct/python/binary
to the configure script. You need Python 2.4 or above.
If you plan to build the Perl bindings, and have a system
with more than one version of perl installed, you may need
to pass
--with-perl5=/path/to/correct/perl/binary
to the configure script. You need Perl 5.8.0 or above.
* Build and install.
Run 'make && make install'
* To verify you have SWIG installed correctly, run "swig
-version"
from the command line. SWIG should report that it is version
1.3.24
or newer.
and then python things
Step 3: Install Specific Language
Bindings
Python
Run 'make swig-py' from the top of the Subversion source tree,
to build the bindings.
(This will invoke SWIG on the *.i files, resulting in a collection
of .c source files. It will then compile and link those .c files
into
Python libraries.)
Run 'make check-swig-py' from the top of the Subversion source
tree, to test the bindings
Run 'make install-swig-py' (as root, typically)
from the top of the Subversion source tree. This will copy
your new Python libraries into the appropriate system location.
Note: If you don't have access to install to Python's site-packages
directory, you can have the Python modules install to your home
directory. You can do this by running
'make install-swig-py swig_pydir=~'.
Note: If you want to install to an alternate prefix (usually only
if you are building packages), you can supply the prefix here. An
example of doing this for building rpms looks like
'make install-swig-py DESTDIR=$RPM_BUILD_ROOT/usr'.
Make sure that whatever directory the bindings got installed
in
is in your Python search path. That directory depends on how you
installed; a typical location is /usr/local/lib/svn-python/.
There are several ways to do this. See Python's documentation for
'sys.path' and 'PYTHONPATH'. A nice way to do this is:
$ echo /usr/local/lib/svn-python \
/usr/lib/python2.x/site-packages/subversion.pth
You may also need to update your operating system's dynamic linker
configuration to enable Python to load these new libraries. On some
systems this is done by running 'ldconfig'.
It may be that the Subversion Python bindings are compiled against a too-old version of Subversion, but given FS format 2 is pre-1.0, it's possible something else is wrong. You can get the Subversion client library version like this:
>>> import svn.client
>>> svn.client.svn_client_version().major
1
>>> svn.client.svn_client_version().minor
6
>>> svn.client.svn_client_version().patch
5
Looks like these guys answered your question pretty thoroughly but FYI: setup the log file so you can read it during your next problem. In your trac.ini somewhere:
[logging]
log_file = trac.log
# log_format = <inherited>
log_level = DEBUG
log_type = file
After that, try to deploy trac to apache if possible - with mod_python or FastCGI the trac documentation says it's a lot faster than running tracd.

How do I set up Setuptools for Python 2.6 on Windows?

Is there any way to install Setuptools for Python 2.6 in Windows without having an exe installer?
There isn't one built at the moment, and the maintainer of Setuptools has stated that it will probably be a while before he'll get to it.
Does anyone know of a way to install it anyway?
First Option - Online Installation (i.e. remaining connected to the Internet during the entire installation process):
Download setuptools-0.6c9.tar.gz
Use 7-zip to extract it to a folder(directory) outside your Windows Python installation folder
Go the folder (refer step 2) and run ez_setup.py from the corresponding dos (command) prompt
Ensure that your PATH includes the appropriate C:\Python2X\Scripts directory
Second Option:
Download setuptools-0.6c9.tar.gz
Download setuptools-0.6c9-py2.6.egg to a folder(directory) outside your Windows Python installation folder
Use 7-zip to extract ez_setup.py in the same folder as setuptools-0.6c9-py2.6.egg
Go to the corresponding dos prompt and run python ez_setup.py setuptools-0.6c9-py2.6.egg from the command prompt
Ensure that your PATH includes the appropriate C:\Python2X\Scripts directory
Third Option (assuming that you have Visual Studio 2005 or MinGW on your machine)
Download setuptools-0.6c9.tar.gz
Use 7-zip to extract it to a folder(directory) outside your Windows Python installation folder
Go the folder (refer step 2) and run python setup.py install from the corresponding dos (command) prompt
Please provide feedback.
You could download and run http://peak.telecommunity.com/dist/ez_setup.py. This will download and install setuptools.
[update]
This script no longer works - the version of setuptools the it downloads is not at the URI specified in ez_setup.py -navigate to http://pypi.python.org/packages/2.7/s/setuptools/ for the latest version - the script also does some md5 checking, I haven't looked into it any further.
The Nov. 21 answer didn't work for me. I got it working on my 64 bit Vista machine by following the Method 1 instructions, except for Step 3 I typed:
setup.py install
So, in summary, I did:
Download setuptools-0.6c9.tar.gz
Use 7-zip to extract it to a folder (directory) outside your Windows Python installation folder
At a DOS (command) prompt, cd to your the newly created setuptools-0.6c9 folder and type "setup.py install" (without the quotes).
Ensure that your PATH includes the appropriate C:\Python2X\Scripts directory
I'm able to find the EXE doing google,
you can simply download it from following URL, and double click and install....
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11.win32-py2.6.exe#md5=1509752c3c2e64b5d0f9589aafe053dc
I got it working quickly by downloading the source and then running (from the extracted directory):
python.exe setup.py bdist_wininst
That builds dist\setuptools-0.6c9.win32.exe, which is exactly the installer you're looking for.
Just installed setuptools as follows:
Downloaded http://pypi.python.org/packages/source/s/setuptools/setuptools-0.6c9.tar.gz#md5=3864c01d9c719c8924c455714492295e , and extracted to a folder outside of my Python installation.
command prompt, then cd into that folder.
enter python setup.py install
That will install from the source into your python's site-packages folder and any other steps needed. This was on Windows XP SP2.
The "first option" (4 steps: download, extract, run, verify PATH) didn't work on my Windows Server 2008 x64 machine with Python 2.6 32 bit installed, nor did it work on my Vista x64 machine with Python 2.6 32 bit installed.
The "second option (5 steps: download, extract, extract, run, verify PATH) worked on both Windows Server 2008 x64 and on Windows Vista x64.
Thanks a bunch for providing the instructions!
OP option 1 did not work for me.
However doing setup.py install as mentioned by NathanD did do the trick.
Maybe that should become option 1?
Werner
The easiest setuptools installation option is to use the pre-packaged Windows Installer.
for 32-bit Python on Windows, the official setuptools page has been updated and has windows installers for Python 2.6 and 2.7:
http://pypi.python.org/pypi/setuptools
for 64-bit Python on Windows, setuptools Windows installers are available here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/
setuptools has been updated in version 0.6c11.
My advice is to wait until Python 2.6.2 to use Python 2.6 on Windows. There are still some bugs that make it less than ideal (this one is particularly nasty). Personally, I wasn't able to get setuptools working totally well on Vista x64 even after installing from source. Under Python 2.5.4, I haven't had any problems though.
Second option worked for me.
Two notes:
a. After installing, when you using easy_install in vista, do so as administrator. (Right click on your command line shortcut and click "run as administrator"). I had trouble trying to run easy_install without doing that.
b. He means use ez_setup from setuptools-0.6c9.tar.gz
Python has everything on board to do this.
from https://pypi.python.org/pypi/setuptools#installing-and-using-setuptools I got the URL to the ez_setup.py: https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py
instead downloading it and fiddling with the file we can do this from the console:
import urllib
url = 'https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py'
ezcode = urllib.urlopen(url).read()
exec(ezcode)
ActivePython already includes setuptools (Distribute actually), along with pip and virtualenv.

Categories