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
What is best practice for working on a Python library package?