universal-ctags / ctags-snap Goto Github PK

The docs at http://docs.ctags.io/en/latest/index.html describe themselves as "developer oriented docs", and point users to ctags.1 man page. But the snap does not appear to install any man pages. (whereas the .deb does)

Started failing around 15th Jan 2022.

Builds for i386 still pass (and the resulting snap installs and works)

Builds for all other architectures give a traceback about str or bytelike in stdlib quote.shlex, eg:
https://snapcraft.io/universal-ctags/builds/1676319

Nothing about this snap repo has changed in a long time, Although the underlying ctags releases are changing all the time.

• TODO: Damien reports this is easy to reproduce locally, clone the repo and snapcraft build --use-lxd.
• TODO: Now that I come to think of it, check that the snaps for different architectures are correctly building ctabs for the correct architecture, remind myself how that works.

Almost zero users use i386 - everyone uses amd64, so this needs fixing if the snap is to remain viable.

Optional compiled features are reported by ctags --version.

Our current snap, 0.2019-12-16+17:58:20+e0a976d7, reports:

Universal Ctags 0.0.0(e0a976d7)...
Compiled: Dec 16 2019, 17:58:44
...
Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +xpath, +json, +interactive, +yaml, +packcc

The 'apt' installed ctags reports:

Universal Ctags 0.0.0...
Compiled: Jan 6 2019, 23:23:29
...
Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +xpath, +json, +interactive, +sandbox, +yaml

ie. the snap is missing "+sandbox"

and the snap has "+packcc" but the apt does not.

Maybe we should make the snap the same as the apt? Or maybe the apt makes bad choices and we should just include what we think is best? Before deciding, we ought to look up what the compile-time features actually do. eg. maybe +packcc was introduced since the apt release was compiled 11 months ago, so we could keep it enabled, on the assumption that future apt releases will include it.

When users look in the store at our snap, or consult "snap info universal-ctags", they see version numbers of the form:

• major = 0
• minor = 2
• patch = (hyphen separated):
  • year
  • month
  • date
  • first 8 chars of universal-ctags commit from which this build was made

eg. 0.2.2018-09-21-39e840e6

It seems that there is no lxd-clients package in Ubuntu 18.

In this Travis CI build you can see how ctags is executed three times:
https://travis-ci.org/daedaleanai/reqtraq/builds/625770261?utm_source=github_status&utm_medium=notification

First call succeeds and /home/travis/x123y456 is created fine, but if the output file is set to /tmp/x123y456 the file is not created and universal-ctags does not report any error.

$ ls -al /tmp
total 68
drwxrwxrwt 14 root   root   4096 Dec 16 16:44 .
drwxr-xr-x 24 root   root   4096 Dec 16 16:43 ..
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .font-unix
drwxrwxr-x  2 travis travis 4096 Dec 16 16:44 gimme
-rw-rw-r--  1 travis travis   71 Dec 16 16:43 hosts_127_0_0_1
-rw-rw-r--  1 travis travis  265 Dec 16 16:43 hosts_sans_127_0_0_1
-rw-rw-r--  1 travis travis  356 Dec 16 16:43 hosts.tmp
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .ICE-unix
drwx------  3 root   root   4096 Dec 16 16:43 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-chrony.service-1cssYY
drwx------  3 root   root   4096 Dec 16 16:42 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-haveged.service-lJlyEb
drwx------  3 root   root   4096 Dec 16 16:42 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-systemd-resolved.service-PI4I4x
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .Test-unix
drwx------  2 travis travis 4096 Dec 16 16:44 tmp.JTfhBtZ43L
drwxrwxr-x  3 travis travis 4096 Dec 16 16:43 travis
drwxrwxr-x  3 travis travis 4096 Dec 16 16:43 v8-compile-cache-2000
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .X11-unix
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .XIM-unix
The command "ls -al /tmp" exited with 0.

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /home/travis/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /home/travis/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1" exited with 0.

$ cat /home/travis/x123y456
!_TAG_FILE_FORMAT	2	/extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED	0	/0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHOR	Universal Ctags Team	//
!_TAG_PROGRAM_NAME	Universal Ctags	/Derived from Exuberant Ctags/
!_TAG_PROGRAM_URL	https://ctags.io/	/official site/
!_TAG_PROGRAM_VERSION	0.0.0	/9fcdb065/
!_TAG_OUTPUT_MODE	u-ctags	/u-ctags or e-ctags/
!_TAG_OUTPUT_FILESEP	slash	/slash or backslash/
getNumberOfSegments	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^uint8_t System::getNumberOfSegments() {$/;"	line:14
getSegment	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^const PcieSegment *System::getSegment(uint8_t i) {$/;"	line:20
enumerateObjects	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^void enumerateObjects() {$/;"	line:30
The command "cat /home/travis/x123y456" exited with 0.

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /tmp/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /tmp/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1" exited with 0.

$ cat /tmp/x123y456
cat: /tmp/x123y456: No such file or directory
The command "cat /tmp/x123y456" exited with 1.

As you can see, the /tmp folder is writable, so the write error should be reported accordingly. If the stdout is redirected to the file it works fine:

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f - /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1 > /tmp/x123y456
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f - /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1 > /tmp/x123y456" exited with 0.

$ cat /tmp/x123y456
getNumberOfSegments	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^uint8_t System::getNumberOfSegments() {$/;"	line:14
getSegment	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^const PcieSegment *System::getSegment(uint8_t i) {$/;"	line:20
enumerateObjects	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^void enumerateObjects() {$/;"	line:30

(Any reason against working around the issue by using the stdout?)

Make a new release of the latest ctags.

First, go read about snapstore process forchannels / tracks.
Presumably we release on 'edge' first, then promote?

When manually triggered
Then Travis CI runs a build and test of this repo's current state
and fails if a valid tags file is not generated

Our entry in the snap store looks a bit bare:
https://snapcraft.io/universal-ctags

• Populate all those fields (done)
• Consider an icon. How about this one: https://iconarchive.com/show/small-n-flat-icons-by-paomedia/tag-icon.html ? (Filed the idea for discussion at universal-ctags/ctags#3298)
• add user documentation, including:
  • link to ctags.io and online man pages (done)
  • names of executables we install (done)
  • the fact we don't install man pages (done)
  • cannot access files outside home dir (done)
  • cannot access hidden home dir files (done)
  • other known bugs or shortfalls that ctags users ought to know about (done)

$ ctags

Command 'ctags' not found, but can be installed with:

sudo apt install exuberant-ctags  # version 1:5.9~svn20110310-12, or
sudo apt install universal-ctags  # version 0+git20181215-2

Could it also suggest our snap, which it does with:

$ universal-ctags

Command 'universal-ctags' not found, but can be installed with:

sudo snap install universal-ctags

Should we provide snaps for multiple architectures?

[✅] Review: https://snapcraft.io/docs/architectures
[✅] Build the releases for alternate architectures (amd64, arm64, armhf, i386, ppc64el, s390x)
[✅] Release them to candidate
[ ] Parameterize the hardcoded 'amd64' in the test script.
[ ] Await downloads of the new architectures
[ ] Promote each to stable if no issues reported after a few days

Hi!

It seems the snap package does not include the readtags command shipped with ctags in other packaging. I cannot seem to find a separately packaged readtags either.
So I either have to build ctags from source or install a four years old version of ctags from the apt repository...

Is there an alternative? Could readtags be packaged with this snap, or in a separate snap?

Thanks for this great tool!

I want to install ctags-snap on a linux server without internet access. Does snap support install/run using a single file like appimage? if so, provide files in the release page?

Using a multiline regex seems to give strange results. The example below shows the tag output pointing to an empty line, but in real code it will point to other non-associated functions elsewhere in the file, not just empty lines.

The name of the parser: C (with custom regex)

The command line you used to run ctags:

$ ctags --options=NONE --mline-regex-c='/MOCK_IMPL\([^,]+,\W*([a-zA-Z0-9_]+)\W*,/\1/f/' test.c

The content of input file (empty lines indicated since GitHub will remove them):

<empty line>
MOCK_IMPL(int,
test_function,(int x, int y)
<empty line>

The tags output you are not satisfied with:

test_function   test.c  /^$/;"  f

The tags output you expect:

Something other than an empty line, such as:

test_function   test.c  /^test_function,(int x, int y)$/;"  f
...

The version of ctags:

$ ctags --version
Universal Ctags 0.0.0(9fcdb065), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Nov  6 2019, 22:41:07
  URL: https://ctags.io/
  Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +packcc

How do you get ctags binary:

From the snap package.

snapcraft failed with following message:

Building universal-ctags 
env NOCONFIGURE=1 ./autogen.sh
+ type autoreconf
autoreconf is /usr/bin/autoreconf
+ type pkg-config
pkg-config: not found
+ exit 1
Failed to run 'env NOCONFIGURE=1 ./autogen.sh' for 'universal-ctags': Exited with code 1.
Verify that the part is using the correct parameters and try again.

Neither .deb nor snap install an 'etags' executable, which is prominently referenced throughout the man page.

The new snap maintainer (@tartley) does not yet understand what version numbers to use on snap releases. Does the ctags repo have tags or releases, or is some other mechanism used to decide when to package a release? What do the other packaging formats do?

The README brilliantly describes the procedure to build the snap, install it, and test the installed executable. This process, or an equivalent to it, should be automated so it can be run regularly by contributors, without fear of typos, and automatically run on releases, by CI, etc.

The current snap uploaded to the store installs the executable name universal-ctags.ctags.

This causes problems, in that universal-ctags considers filenames ending with .ctags are "optfiles" for defining a command line based parser.

Please rename the installed executable to universal-ctags.

Also, create an automatic alias of ctags. Don't forget to remove the README section about manually creating that alias.

Asking ctags to read from hidden files or directories fails:

ctags --options=/home/peara/.vim
ctags: cannot open option directory "/home/peara/.vim" : Permission denied

I speculate that a similar failure will occur if ctags is asked to examine files outside the user's home directory.

(Originally described in universal-ctags/ctags#2017.)

implementation notes

Currently, this builds ctags with the home interface. However, this plugin only allows access to non-hidden files in home directory.

One possible fix is to use persornal-files interface which allows access of such files. However, this only allows access to particular filenames specified in the snap build (eg. ~/ctags.d) Users will still be unable to access files with names other than those we specify.

Another possible fix is to build the snap in "classic" mode. This requires removing the 'strict' declaration in our snapcraft.yaml. I'm not yet sure what the trade-offs are. I'll go read...