Package Details: python2-cheetah3 3.2.5-4

Git Clone URL: https://aur.archlinux.org/python-cheetah3.git (read-only, click to copy)
Package Base: python-cheetah3
Description: A Python powered template engine and code generator
Upstream URL: http://www.cheetahtemplate.org
Licenses: MIT
Submitter: alexbrinister
Maintainer: alexbrinister (fryfrog)
Last Packager: fryfrog
Votes: 7
Popularity: 0.56
First Submitted: 2018-07-30 02:37
Last Updated: 2020-05-19 15:31

Dependencies (3)

Required by (1)

Sources (1)

Latest Comments

1 2 Next › Last »

fryfrog commented on 2020-11-09 00:18

For the heck of it, I also tested building it in a clean chroot and that was fine too, so you've got something special going on.

fryfrog commented on 2020-11-09 00:14

I just built both fine on my system. Maybe don't bother building the python2-cheetah3?

xunil commented on 2020-11-09 00:07

I get this error when trying to install:

/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'long_description_content_type'
  warnings.warn(msg)
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'project_urls'
  warnings.warn(msg)
Traceback (most recent call last):
  File "setup.py", line 12, in <module>
    SetupTools.run_setup(configurations)
  File "/mnt/data2/yaourt-tmp/yaourt-tmp-xifizurk/aur-python-cheetah3/src/Cheetah3-3.2.5-py2/SetupTools.py", line 147, in run_setup
    setup(**kws)
  File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/lib/python2.7/site-packages/distribute-0.6.28-py2.7.egg/setuptools/dist.py", line 225, in __init__
    _Distribution.__init__(self,attrs)
  File "/usr/lib/python2.7/distutils/dist.py", line 287, in __init__
    self.finalize_options()
  File "/usr/lib/python2.7/site-packages/distribute-0.6.28-py2.7.egg/setuptools/dist.py", line 258, in finalize_options
    ep.load()(self, ep.name, value)
  File "/usr/lib/python2.7/site-packages/distribute-0.6.28-py2.7.egg/pkg_resources.py", line 2022, in load
    raise ImportError("%r has no %r attribute" % (entry,attr))
ImportError: <module 'setuptools.dist' from '/usr/lib/python2.7/site-packages/distribute-0.6.28-py2.7.egg/setuptools/dist.pyc'> has no 'check_specifier' attribute

fryfrog commented on 2020-02-10 03:29

Looks like I goofed up and had setuptools as a depends instead of makedepends. Should be sorted now.

Orionis commented on 2020-02-09 22:16

That was odd. When updating from 3.2.4-2 to 3.2.4-3 yay didn't install setuptools, so I ran into an error updating. After installing setuptools manually the update went fine.

fryfrog commented on 2020-01-27 03:51

@alexbrinister, I've got the updated PKGBUILD all worked up and submitted a merge request for my python2-cheetah3. I'll push it once they approve, usually takes a day or seven. :)

alexbrinister commented on 2020-01-27 03:39

@fryfrog A split package is probably the way to go. I will make you a co-maintainer so you can make the changes for split package.

fryfrog commented on 2020-01-01 21:15

Hey @alexbrinster, it looks like python2-cheetah was removed from community. I needed it for sabnzbd, so I've created a python2-cheetah3. In that one, I named the binaries cheetah2 and such, so if you wanted you could flip yours to not put a 3 in them.

Also, if you wanted to make this a python/python2 split package... that'd be cool too and I could merge mine into yours. Happy to do it myself, if you like. Can submit a patch or you can make me co-maintainer or whatever.

stardiviner commented on 2019-11-22 11:01

@alexbrinister Thanks, I use command deactive to disable user virtualenv. It is installed correctly. Thanks very much. :)

alexbrinister commented on 2019-10-17 22:29

@stardiviner I have reproduced your issue. Are you in a virtualenv when you build the package? This would mess up the directory into which python installs the package. If you build the package in a virtualenv, the package files will end up being installed into your home directory (or wherever you have your virtualenv set to) by pacman. I have tested this with another python package from the AUR and the files are indeed installed in the virtualenv. Since most packages do not need to change names of binaries, there is no issue, other than the package files being installed in the virtualenv as opposed to the default location (/usr).