We Keep Coding

Is it possible (and how) to see the Python source code for the package that is installed with 'pip install package-name'?

Is it possible (and how) to see the Python source code for the package that is installed with 'pip install package-name'? I have found wheels file, but it is in compiled format. Installation messages are also talking about building and installing, so, I guess, that only compiled code is available on my computer now?

Run pip show --files package-name. See the full paths to the files. View *.py files.
There are some modules and packages written in C or C++ — you cannot see their sources after installation, you have to find out their source code. Start looking for package-name at PyPI.
wheels file … in compiled format
No, it's not. It's a zip archive. You can unzip it. Probably you can click or double-click on it in your file manager — most file managers recognize zip archives and show their content.

Where is python.exe in a Windows tarball installation?

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.

Building PyCrypto with fastmath (gmp or mpir) via pip on Windows

I installed PyCrypto on Windows via pip but i was not able to build Crypto.PublicKey._fastmath because GMP was not found.
I know there is a binary version on voidspace but i would like to build the latest version of PyCrypto

The following one is a way to achieve your goal. There are other, probably better ways (e.g. based on Visual Studio), but this one has worked for me. Additionally, it does not use pip.
All operations are carried out on a command prompt.
Install Mingw, including MSYS and the Development Toolkit. This will give you a fairly complete Unix-like development environment.
Ensure that Mingw binaries are in PATH environment variable. You need MinGW\bin and MingGW\msys\1.0\bin.
Download MPIR sources in a temporary directory. It is important you do not use 2.5.1 because of a bug that will break the build. 2.5.0 is fine.
Build the MPIR library. This is fairly straightforward: execute bash configure followed by make.
HACK #1 Copy libmpir.a from mpir-2.5.0\.libs into C:\Python2.7.1\libs. This is necessary because distutils is broken and I could not find a way to direct it to the correct library location.
HACK #2 Edit C:\Python2.7.1\Lib\distutils\cygwincompiler.py and remove any occurrance of the string -mno-cygwin. The reason is explained here.
Download PyCrypto sources and unpack them in another temporary directory.
Set CPPFLAGS environment variable to the MPIR directory, which contains mpir.h.
HACK 3 Edit setup.py and add the following line in build_extension method:
self.__add_compiler_option(os.environ['CPPFLAGS'])
Run bash configure. You should see two lines saying:
checking for __gmpz_init in -lgmp... no
checking for __gmpz_init in -lmpir... yes
Execute python setup.py build -c mingw32. You should see no errors.
Execute python setup.py test to verify that everything is fine.
Execute python setup.py install to copy the files into your local Python repository.
Alternatively, run python setup.py bdist_wininst to create an installer.
I really hate all the various hacks, and I'd love to hear if they can be avoided.

How to install Trac Plugin and what is a python egg?

In Trac on Admin -> Plugins there is an option to install Plug-ins. Now this option expect you to upload an Python egg.
This would be all well but for the fact that all the Trac plug-ins I found are either plain .py files or zip files and are incompatible with the upload function (I tried it).
This leaves my with a bunch of questions:
Are there any Trac plug-ins which come as an Python egg?
What is an (Trac compatible) Python egg?
Is it difficult to repackage an .py file into a Trac compatible Python egg?
If not: how is it done?

Haven't used trac for a year, but what I remember is that most plugins are available trough subversion and already packed as an egg (which is kind of an installer in the python world, but I am not very familiar with the concept).
Most plugins are available at http://trac-hacks.org/ and the easiest way to install a plugin is
easy_install http://svn.domain.tdl/path/to/plugin/
the folder should contain a setup.py and a setup.cfg file.
easy_install checks the files out from svn and installs the plugin. You can find details here: http://trac.edgewall.org/wiki/TracPlugins
If the plugin makes database changes you have to call
trac-admin upgrade
from console.
http://trac.edgewall.org/wiki/TracAdmin
If I remember right, the install through the webinterface installs the plugin locally (for the instance) while easy_install installs it globally (for all running trac sites) and is the more common way to install a plugin.
Hint: After every plugin install you have to restart trac
Hint2: Most plugins don't tell you how to install and only give a link to the root of their svn. You only have to browse the svn folder and locate the folder containing the setup.py.
The rest is done with easy_install.
Example:
Plugin: http://trac-hacks.org/wiki/GoogleChartPlugin
Wiki pages tells you:
You can check out GoogleChartPlugin from here using Subversion, or browse the source with Trac.
where here links to http://trac-hacks.org/svn/googlechartplugin/
The svn contains two versions. Browse to http://trac-hacks.org/svn/googlechartplugin/0.11/trunk/ and copy the path.
Then do
easy_install http://trac-hacks.org/svn/googlechartplugin/0.11/trunk/

Answers to your questions in order.
Python eggs are binary packages which contain the code for the application and some metadata. They're not very different from debs or rpms in this sense. The egg itself is basically just a zip file which contains all the above mentioned files with specific names and layouts. For more information on eggs (the format and how to create them), please refer to http://www.ibm.com/developerworks/library/l-cppeak3.html. It's probably a little dated since the future (and present) of python packaging is a little hazy.
A trac plugin is a python program that uses the Trac plugin API to extend the functionality of trac. It can be packaged as an egg.
If your package is properly laid out and contains a setuptools/distribute setup.py file, then issuing the command python setup.py bdist_egg will create a .egg file for you. For details on this please refer to this(a little dated but complete) and this (more upto date but still in progress). The Trac Growl plugin mentions this on it's documentation page.
Please see above point.

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.