| Commit message (Collapse) | Author | Age |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* CHANGE ``message_extractors`` to use the ``pkgpath`` variable. The less
places in the code with arbitrary hardcoded paths which may change at some
point, the better.
* ADD an XXX note about the glob pattern ``public/**`` in
``message_extractors``.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* CHANGE ``exclude_package_data`` to specify the package explicitly. This
seems to fix a bug where .po files were still being installed.
* ADD an exclusion for all .pot files.
* FIXES a bug where lib/bridgedb/i18n/templates/bridgedb.pot was being
installed by setuptools.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ``get_data_files()`` function now takes a boolean ``filesonly`` parameter,
if True, it returns a list suitable for the ``package_data`` parameter of
``setuptools.setup()``, otherwise it returns a list which is compatible with
``distutils.command.install_data.install_data.data_files``.
We can now remove distutils entirely from setup.py, but I decided to make this
function compatible with both distutils and setuptools because Python
packaging has been in turmoil for a while now. (Hopefully, it's done, but I'm
not holding my breath.)
* FIXES a problem with some .mo files not getting installed (if they didn't
already have a directory for their LOCALE in build/).
* FIXES a bug where all .po files were being installed, even though they were
added to the ``exclude_package_data`` parameter of ``setuptools.setup()``.
* FIXES (along with commit ef784165002086cbc5b8131edcde815326a63009) a bug
where the robots.txt file was not being packaged correctly.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* ADD ``glob`` dependency to setup.py.
* ADD ``get_template_files()`` function to setup.py, which simply globs for
filenames which match various directory patterns, in order to obtain files
which should be installed for BridgeDB's HTTPS distributor.
* FIXES a bug where robots.txt was not being installed as a resource file.
|
| | | |
| | |
| | |
| | | |
Might as well, while we're at it.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* ADD function ``get_supported_langs()`` to setup.py, which determines which
completed, compiled translations files are present in our source tree, and
stores three things:
1. The LOCALE code for the translation.
2. The path of the directory to install the files to, relative to the
current ``sys.prefix``. (``sys.prefix`` is where Python files are
going to be installed, and it is set by the OS's interpreter first,
and then occaisionally changed according to various factors, like
whether or not we are working in a virtualenv, if the package is being
installed from a DCVS/egg/tarball/zipfile, if the package is being
installed via pip or via a package manager, etc.)
3. A list of files for that LOCALE which should be installed. In our
case, this should only ever be one <LOCALE>/LC_MESSAGES/bridgedb.mo
file per LOCALE.
These three things allow us to tell both setuptools (and the underlying
distutils mechanisms) how/where to install everything.
The next thing that ``get_supported_langs()`` does is take the list of
collected LOCALEs which are to be installed, and rewrite a line in the
following new module:
* ADD a new module, lib/bridgedb/_langs.py, which has one variable,
``supported``, which is a list of two-letter country codes of languages
installed. When "python setup.py install" is run (or any setup.py command,
for that matter) the ``supported`` variable in lib/bridgedb/_langs.py is
rewritten to be the current list of languages for which we have completed,
compiled translation files.
* ADD function ``get_langs()`` to lib/bridgedb/_langs.py. This simply fetches
the current value for ``supported``.
* ADD a package attribute, ``bridgedb.__langs__``, which uses ``get_langs()``
to store, in the installed version of BridgeDB, the list of supported
languages which were also installed. :)
* ADD an entry for ``lib/bridgedb/_langs.py`` into .gitignore, so that a
locally rewritten file is never committed.
|
| |/ / |
|
| |\ \ |
|
| |/ / |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
* REMOVE one EOL whitespace, a blankline with extra whitespace.
* FIX a tab before a space.
|
| |/ / |
|
| | |
| |
| |
| |
| | |
* CHANGE Makefile directives 'install' and 'force-install' to recompile the
completed translations before actually installing the package.
|
| |\ \ |
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
It seems that BridgeDB won't answer a request until it knows what language to
answer in. If English is the first language, and there aren't English
translations in the i18n/ directory, it jumps to the next non-English
language. Don't ask.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* ADD maint/get-completed-translations script for pulling in the
'bridgedb_completed' branch from the translations repo. At the end of the
script there is the option to automatically run "python setup.py
compile_catalog" to recompile the newly merged translations; this option
times out after 15 seconds, so this is safe to run in an automated
environment.
* ADD "make translations" command to the Makefile, this will run the
maint/get-completed-translations script.
|
| | | |
| | |
| | |
| | | |
This shouldn't have been committed anyway.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
* ADD exclude_package_data directive to setuptools.setup() call, to exclude
all .po files from being installed.
* FIX the crunchbang in setup.py to respect the environment and save the
whales and all that.
* UPDATE the copyright/authors/license header. I hear it's not 2007 anymore.
|
| | |
| |
| |
| |
| | |
* ADD scripts/gen_bridge_descriptors to setup.py so that the crunchbang is
appropriately rewritten upon installation.
|
| | |
| |
| |
| | |
Thanks to mrphs for pointing out on IRC that python-dev was missing.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The 'feature/9937-desc-gen-r1' branch is actually the entirety of a separate
repo, https://github.com/sysrqb/tdgen from the master branch. It was merged by
doing:
$ git clone https://github.com/sysrqb/tdgen && cd tdgen
$ cd ../bridgedb
$ git checkout -b feature/9937-desc-gen develop
$ git remote add tdgen ../tdgen
$ git fetch tdgen
$ git merge -S --no-ff tdgen/master
|
| | | |
| | |
| | |
| | | |
It should be better this way.
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* ADD commands 'test' and 'coverage' to scripts/bridgedb. To run
twisted.trial based unittests, after BridgeDB has been installed, do:
$ bridgedb test
and to run the same tests under python-coverage, do:
$ bridgedb coverage
* ADD dependencies for unittests and coverage:
- coverage
- trialcoverage
- sure
* FIXES #9872
|
| | |
| |
| |
| | |
* This should also help save the whales.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We guess which language gettext will choose by iterating over
the languages in the Language header and selecting the first
one we support. We assume a user will prioritize languages in
their browser. We then render the page using the selected
language, or English if it is no available. Bug fix on #9157.
(cherry picked from commit a31c592eadd72a659f22497f66e77fb90c6c207b)
Signed-off-by: Isis Lovecruft <isis@torproject.org>
Taken from branch 'sysrqb/bug9157_r2_rebased'.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
* TODO We need a separate place (and preferably git repo for maintainer
docs, scripts, etc.). I've started putting these things in maint/ in
the top-level of bridgedb.git, but since I think that service
maintainance should be kept separate from the software maintainance,
I haven't committed them yet. That said, here are the instructions
for bumping versions, for lack of a better place to put them.
|
| |\ \
| |/ |
|
| | |\
| |/
|/| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It isn't actually a module, it's a two-line script. Installing it as a script
is better, because:
1) We don't need to do `python -m TorBridgeDB […]`. Instead, we just do
`bridgedb […]` and we also get all the benefits of shell autocompletion.
2) Setuptools will automatically replace the #! in the installed script to
point to the location of the Python interpreter which was used to install
it, making it work with alternate interpreters as well as within
virtualenvs.
* MOVE lib/TorBridgeDB.py → scripts/bridgedb.
* ADD 'scripts' arguments to setuptools.setup() call.
* UPDATE the README with instructions on how to run bridgedb now.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* ADD function get_requirements() to setup.py file, for parsing the
requirements.txt file and installing the dependencies specified there. This
allows us to keep one place for keeping track of dependencies, regardless
of whether we are installed from a source distribution (git or a tarball)
or with pip.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* FIXES part of #9425 (Create and document a better BridgeDB deployment
strategy).
* ADD versioneer.py to the top level of the project.
* USE setuptools explicitly in setup.py, which will also make the project a
bit more py3k compatible.
* ADD maintainer and maintainer_email fields to setup.py setup() call (with
my contact info).
* ADD versioneer setup variables and calls to setup.py.
Versioneer, as currently configured, will automatically create a package level
attribute:
>>> import bridgedb
>>> print bridgedb.__version__
0.0.1
Bumping the version number at release time (which, for BridgeDB really means
deploy time, as of right now) means doing the following:
$ git checkout develop
[merge some fix/bug/feature/etc branches]
$ git checkout -b release-0.0.2 develop
$ git tag -a -s bridgedb-0.0.2
[pip maintainance commands *would* go here, if we ever have any]
$ git checkout master
$ git merge -S --no-ff release-0.0.2
$ git checkout develop
$ git merge -S --no-ff master
$ git push <remote> master develop
And be sure not to forget to do:
$ git push --tags
If the currently installed version is *not* from one of the signed tags, the
version number attribute created by versioneer will be the short ID of the git
commit from which the installation took place, prefixed with the most recent
tagged release at that point, i.e.:
>>> import bridgedb
>>> bridgedb.__version__
0.0.1-git528ff30c
|