Wrong doc for activate-global-python-argcomplete

Documentation says that the command for global autocomplete with dest folder specification should be
activate-global-python-argcomplete --dest=/path/to/bash_completion.d
but actually the syntax with --dest= is rejected:
$ activate-global-python-argcomplete --dest=~/.local/share/bash-completion/completions
usage: activate-global-python-argcomplete [-h] [--dest DEST] [--user]
[--no-defaults]
[--complete-arguments ...]
As the help reports, a space must be used instead:
$ activate-global-python-argcomplete --dest ~/.local/share/bash-completion/completions
Installing bash completion script /home/rossellom/.local/share/bash-completion/completions/python-argcomplete

Furthermore, I found out that (at least on Ubuntu 18.04) the working installation as a user is to run:
activate-global-python-argcomplete --dest=- >> .bash_completion
First, the ~/.bash_completion.d/ folder is not considered at all, and the working local folder for autocompletion scripts is ~/.local/share/bash-completion/completions instead. But, secondly, this folder is used for dynamic autocompletion, so the script name should have exactly the name of the autocompleted command, which is not the case for generic autocompletion. Hence my suggestion above.

I can't reproduce this; the command line works the same for me both ways. The parser is built using argparse, which has supported both forms by default for as long as I've used it. Are you certain that syntax doesn't work? Which version of Python are you using?

Never mind, I think I've worked out the problem. The important part is the error message after the usage:
usage: activate-global-python-argcomplete [-h] [--dest DEST] [--user]
                                          [--no-defaults]
                                          [--complete-arguments ...]
activate-global-python-argcomplete: error: Path ~/.local/share/bash-completion/completions does not exist

Bash doesn't appear to perform ~ expansion with the dest=~/... form.
Strictly speaking there's nothing wrong with the syntax in the documentation since the example does not include ~, however I agree it would probably be nice to change it to the form that won't break for paths that do.

Thanks @evanunderscore for your response!
Maybe it's argparse's problem, but note that the misinterpretation arose from the fact that using ~ with a space does work:
$ activate-global-python-argcomplete --dest ~/.local/share/bash-completion/completions
Installing bash completion script /home/rossellom/.local/share/bash-completion/completions/python-argcomplete
What about the fact that ~/.bash_completion.d is not considered in Ubuntu and that for a default complete rule to be loaded for user ~/.bash_completion is the working choice?
Thanks a lot for the awesome project!

@evanunderscore thanks for tracking that down, we should just use https://docs.python.org/3.8/library/os.path.html#os.path.expanduser - we could even use this shorthand: parser.add_argument(..., type=os.path.expanduser)

@maxrossello

What about the fact that ~/.bash_completion.d is not considered in Ubuntu and that for a default complete rule to be loaded for user ~/.bash_completion is the working choice?

The following link provides a comprehensive review of your options: https://serverfault.com/a/831184
It looks like you need bash-completion >= version 2.9 for ~/.bash_completion.d to work.

@evanunderscore thanks for tracking that down, we should just use https://docs.python.org/3.8/library/os.path.html#os.path.expanduser - we could even use this shorthand: parser.add_argument(..., type=os.path.expanduser)

great!

The following link provides a comprehensive review of your options: https://serverfault.com/a/831184
It looks like you need bash-completion >= version 2.9 for ~/.bash_completion.d to work.

Well, no. The link you provide depicts a manual workaround for version <= 2.8 involving ~/.bash_completion.d as an arbitrarily chosen folder where to store scripts eagerly loaded from ~/.bash_completion through a customly written for loop. Looks like ~/.bash_completion.d has never been considered as a relevant folder by bash-completion.
In fact, even in 2.9 (cfr https://github.com/scop/bash-completion/tree/2.9) no ~/.bash_completion.d folder is mentioned, and the default user folder is the one already working for on demand loading in my 2.8 installation, i.e. ~/.local/share/bash-completion/completions (or $XDG_DATA_HOME/bash-completion/completions if $XDG_DATA_HOME exists).
But as I said before, that target folder works only for on demand completion, which means that a script named python-argcomplete would be loaded on the fly only for a python-argcomplete command. Agreed, once sourced somehow, it would work globally because of the shape of the complete command inside, but that is not the point. Only ~/.bash_completion is loaded eagerly, as explained in the bash-completion FAQ:
Q. Where should I install my own local completions?
A. Put them in the completions subdir of $BASH_COMPLETION_USER_DIR (defaults to $XDG_DATA_HOME/bash-completion or ~/.local/share/bash-completion if $XDG_DATA_HOME is not set) to have them loaded on demand. See also the next question's answer for considerations for these files' names, they apply here as well. Alternatively, you can write them directly in ~/.bash_completion which is loaded eagerly by our main script.

Looks like you're right. We should probably change this script to append directly to ~/.bash_completion or ~/.local/share/bash-completion or whatever that discovery protocol yields.

So far my solution has been to append to ~/.bash_completion, not to delete any existing content
activate-global-python-argcomplete --dest=- >> ~/.bash_completion
I believe that this could first be used in docs, and then maybe the --user option would do the same (including some grep to check if already there not to duplicate?)

Just wanted to provide some feedback on this thread regarding the package python3-argcomplete on Debian Bullseye 11, which fails when executing activate-global-python-argcomplete3:
~# activate-global-python-argcomplete3
usage: activate-global-python-argcomplete3 [-h] [--dest DEST] [--user] [--no-defaults]
                                           [--complete-arguments ...]
activate-global-python-argcomplete3: error: Path /etc/bash_completion.d does not exist

As stated above in this thread, the following command, run as root, works well as equivalent to what --user should do:
activate-global-python-argcomplete3 --dest=- >> ~/.bash_completion
This provided autocompletion to my ansible-playbook command, run as root, which was the desired outcome.
Moreover, when trying to install it system-wide:
~# activate-global-python-argcomplete3 --dest=/usr/share/bash-completion/completions/
Installing bash completion script /usr/share/bash-completion/completions/python-argcomplete.sh

The file was deployed correctly but no autocompletion was happening (as devops user created afterwards). This is strange as the bash-completion Debian package installs the script /etc/profile.d/bash_completion.sh, which sources the file /usr/share/bash-completion/bash_completion and is loaded automatically by the file /etc/profile installed in all users and sourced in their ~/.bashrc files.
Incidentally, using a space character after the dest option instead of an equal sign deployed the file at the correct destination as well. But autocompletion was not working either.
The documentation in /usr/share/doc/python3-argcomplete/ does not instruct the user properly on how to install it. Perhaps the installation script of the package should install and configure it system wide, making use of dh_bash-completion as stated in /usr/share/doc/bash-completion/README.Debian?

$ mkdir -p ~/.local/share/bash-completion/completions
$ echo "activate-global-python-argcomplete --dest ~/.local/share/bash-completion/completions" >>~/.bash_profile


Possible without uid in url?

I would like an url without the uid in the url, is that possible? I’m using the mapper just for the localeMap (I have an extension with one record for both languages english and german and an own slug field for each language). So in my case the PersistedAliasMapper would be fine but PersistedAliasMapper does not have the localeMap.

I solved this now by an own Mapper extending the PersistedAliasMapper and inspiring by your code. Not optimal (in $this->modify(); did not work in function generate so I had to modify findByIdentifier) but works.

Hey, as I think, the PersistedAliasMapper should work with the path_segment instead and localized records will have their own path slugs, I don't see any effort.
But I'm working on an extended routing extension with some other features, so if you want to share your code and possibly show the benefit, I#ll try to implement your solution, too.


Buf::copy_to_bytes

Buf could have copy_to_bytes operation:
fn copy_to_bytes(&mut self, len: usize) -> Bytes;

Default implementation should simply allocate new Bytes, while implementation for Bytes could call slice.

I'd like this too. There's Buf::to_bytes() which consumes the remainder of the buffer, but that's rarely what we want. We need a get_bytes() like we need the other get_*().

Bikeshedding: copy_to_bytes does not sound true to what this method does (as far as I understand). Taking bytes from self should be emphasized, and maybe the potential for zero-copy implementation.
Maybe extract_to_bytes? I've got some prior art, though not as an intrinsic method: StrChunk::extract_utf8


.OVA File Link Not Working

Description of the bug
There is a link for a .OVA file in the README.md. However, this link does not go to a website that can be reached.
Steps to reproduce the bug:

Go to HydroShare GitHub
Scroll down to the README.md
Under the "Install" section there is a "Simplified Installation Instructions" with the first step being to "download the latest .OVA file here"
When clicked, it gives a "This site can't be reached error

Expected behavior
To open to a valid webpage
Additional information
Screenshots:

This will be addressed with PR4281. @martinseul I'm assigning this to you per our discussion. Thanks.

The developer setup using a OVA file has been deprecated and is superseded by a new setup. The setup process outlined on the landing page for the repository  has been updated with the new instructions.  PR#


curl works, confluencebuilder not

If I test my connection with
curl -v https://confluence.mycompany.com/rest/api/space/MYSPACE -H "Authorization: Bearer averylongsecret"

I get a 200. All fine
Using this with confluencebuilder with debugging I get DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/space?spaceKey=MYSPACE&limit=1 HTTP/1.1" 200 None could not find the configured space.
What could be wrong?

@Kugeleis, just to sanity check, for the first request with a 200 response, do you also get expected API data back (i.e. a JSON response showing content like ID, name, etc.). Or do you get an empty 200 response? I assume the former, but the latter would be observed if there was an authentication issue.
I suspect that you are possibly using a PAT and not an API key. I want to make sure for this use case that you are using the configuration option confluence_publish_token (and not confluence_server_pass).
The request response you provided where it states HTTP/1.1 ... 200 None gives me an indication that the request was properly made to an instance, but the response return with no data. This is typically a sign of authentication issues.

With the curl command above I can access my space as wanted (e.g. with curl -v https://confluencewikiprod.intra.infineon.com/rest/api/space/IGBT/content ...) I get the page list etc. Actually I'm using the atlassian confluence API python wrapper with this access method regularly.
I'm using PAT and I provide it to confluence_publish_token. I wrote a gist for you with the syntax which fails with 'could not find the configured space'. This gists code runs flawlessly with my space. I suspect urllib3 is doing something not equivalent to curl.

Hmm... I do not see any immediate solution at this time. I am a bit curious why the connection is not working with this extension. This extension does use Requests, in a similar manner as your second sample. There isn't anything super complex to what this extension does.
Maybe, do you have any other auth-related options set (like confluence_server_user)? This may result in this extension stacking additional authentication options on a Requests session, which in turn may be causing this issues. Mind running a report capture?
python -m sphinxcontrib.confluencebuilder report

Also, do you mind indicating the error message generated when running this extension? I know you mentioned a specific debugging log message, but curious to know what specific message is generated for a generic use for this use case (helpful for tracking and future considerations).
The only other thing that I could ask for (if the above does not cover it or resolve anything) is possibly a more in-depth capture when running with the option confluence_publish_debug set (with the output sanitized with your discretion before attaching it here).

Here is the output of the report:
(system)
 platform: Windows-10-10.0.22621-SP0
   python: 3.11.5 (tags/v3.11.5:cce6ba9, Aug 24 2023, 14:38:34) [MSC v.1936 64 bit (AMD64)]
   sphinx: 7.2.6
 docutils: 0.20.1
 requests: 2.31.0
  builder: 2.4.0

(configuration)
~default configuration~

(error loading configuration)
no documentation/missing configuration

My confluencebuilder config in sphinx conf.py is
confluence_publish = True
confluence_publish_debug = True
confluence_space_key = cf.space_key
confluence_parent_page =<PHONE_NUMBER>
confluence_server_url = cf.domain
confluence_publish_token = cf.token
```
As you see the debug option is on. Finally here is what the command line looks like (complete):

(sphinx) PS C:\pathto\sphinx> sphinx-build -b confluence ./source/ ./build/ -E -a
Running Sphinx v7.2.6
<module 'confluence' from 'C:\pathto\python\sphinx-test\source\confluence\confluence.py'>
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): confluence.mycompany.com:443
DEBUG:urllib3.connectionpool:https://confluence.mycompany.infineon.com:443 "GET /rest/api/space?spaceKey=MYSPACE&limit=1 HTTP/1.1" 200 None
could not find the configured space
(notice to debugging user)
Either the space does not exist, or the user does not have permission to see
the space. Another space search will be performed to sanity check the
configuration to see if a similar space key exists, which can hint to a user
that the space key may be misconfigured. If the following search request
results in an access restriction, it is most likely that the authentication
options are not properly configured, even if the previous search request
reported a success (which can be permitted for anonymous users).
DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/search?cql=type%3Dspace+and+space.title~%22IGBT%22&limit=2 HTTP/1.1" 403 None
sphinxcontrib.confluencebuilder error:

Permission denied on Confluence (rest-call)
The configured user does not have permission to perform an action on the
Confluence instance. If the user should have access and this request is
using a personal access token, ensure the token is not expired/revoked.
(code: 403)

Thanks for the report capture. Seems like the capture failed to process the configuration, but maybe that's expected in your setup if you have a complex Sphinx configuration. Unfortunately it doens't show the explicit configuration options loaded by the builder (but thanks for replicaing the ones you actually used, that helps) -- but more so, it does not have the explicit Confluence data center version you may be using. If you maybe could scroll to the bottom of any Confluence page to indicate the major+minor version (e.g. v8.8), I can spawn up a matching version to compare (if the issue is related to the specific Confluence version).
Interesting observation on the /rest/api/search... API call. It appears to me that Confluence has changed how the search capability may work. I'm not sure off hand if its now broken on my instance, newer Confluence versions or has additional requirements. Spawning an older Confluence instance shows expected results, where newer instances always appear to provide no space counts no matter what is set for the CQL (e.g. even just asking for any spaces). Although, the failure of this specific API is not a major issue for this extension. It was originally added in the past as a way to help search for similar spaces, since it was common at the time were people were complaining that they could not find a space, but turns out they adjusting the casing on the key, causing issues. The search was an attempt to help find similar spaces to suggest an alternative. It might be better if this extension just strips out all this extra logic, does a single space search and stops immediately if the exact match for a key is not found. I'll note to do this when looking at #858.
I was also performing some sanity checks with a local instance, comparing space search results using curl and comparing some of the results with this extension (and some additional prints). I haven't be able find anything yet, but I'll keep looking.

Various curl outputs
$ curl -s "INSTANCE_URL/confluence/rest/api/space/TEST" | json_pp -json_opt pretty,canonical
{
   "data" : {
      "allowedInReadOnlyMode" : true,
      "authorized" : false,
      "errors" : [],
      "successful" : false,
      "valid" : true
   },
   "message" : "No space found with key : TEST",
   "reason" : "Not Found",
   "statusCode" : 404
}

$ curl -s "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST&limit=1" | json_pp -json_opt pretty,canonical
{
   "_links" : {
      "base" : "INSTANCE_URL/confluence",
      "context" : "/confluence",
      "self" : "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST"
   },
   "limit" : 1,
   "results" : [],
   "size" : 0,
   "start" : 0
}

$ curl -s "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST" | json_pp -json_opt pretty,canonical
{
   "_links" : {
      "base" : "INSTANCE_URL/confluence",
      "context" : "/confluence",
      "self" : "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST"
   },
   "limit" : 25,
   "results" : [],
   "size" : 0,
   "start" : 0
}

$ curl -s -H "Authorization: Bearer OMITTED" "INSTANCE_URL/confluence/rest/api/space/TEST" | json_pp -json_opt pretty,canonical
{
   "_expandable" : {
      "description" : "",
      "homepage" : "/rest/api/content/1277954",
      "icon" : "",
      "metadata" : "",
      "retentionPolicy" : ""
   },
   "_links" : {
      "base" : "INSTANCE_URL/confluence",
      "collection" : "/rest/api/space",
      "context" : "/confluence",
      "self" : "INSTANCE_URL/confluence/rest/api/space/TEST",
      "webui" : "/display/TEST"
   },
   "id" : 1310721,
   "key" : "TEST",
   "name" : "TEST",
   "type" : "global"
}

$ curl -s -H "Authorization: Bearer OMITTED" "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST&limit=1" | json_pp -json_opt pretty,canonical
{
   "_links" : {
      "base" : "INSTANCE_URL/confluence",
      "context" : "/confluence",
      "self" : "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST"
   },
   "limit" : 1,
   "results" : [
      {
         "_expandable" : {
            "description" : "",
            "homepage" : "/rest/api/content/1277954",
            "icon" : "",
            "metadata" : "",
            "retentionPolicy" : ""
         },
         "_links" : {
            "self" : "INSTANCE_URL/confluence/rest/api/space/TEST",
            "webui" : "/display/TEST"
         },
         "id" : 1310721,
         "key" : "TEST",
         "name" : "TEST",
         "type" : "global"
      }
   ],
   "size" : 1,
   "start" : 0
}

$ curl -s -H "Authorization: Bearer OMITTED" "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST" | json_pp -json_opt pretty,canonical
{
   "_links" : {
      "base" : "INSTANCE_URL/confluence",
      "context" : "/confluence",
      "self" : "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST"
   },
   "limit" : 25,
   "results" : [
      {
         "_expandable" : {
            "description" : "",
            "homepage" : "/rest/api/content/1277954",
            "icon" : "",
            "metadata" : "",
            "retentionPolicy" : ""
         },
         "_links" : {
            "self" : "INSTANCE_URL/confluence/rest/api/space/TEST",
            "webui" : "/display/TEST"
         },
         "id" : 1310721,
         "key" : "TEST",
         "name" : "TEST",
         "type" : "global"
      }
   ],
   "size" : 1,
   "start" : 0
}

Extension prints on space searchs
extensions = [
    'sphinxcontrib.confluencebuilder',
]

confluence_publish = True
confluence_server_url = 'INSTANCE_URL/confluence/'
confluence_publish_token = 'OMITTED'
confluence_space_key = 'TEST'

Running Sphinx v7.2.6
making output directory... done
...

rsp.status_code: 200
{
    "results": [
        {
            "id": 1310721,
            "key": "TEST",
            "name": "TEST",
            "type": "global",
            "_links": {
                "webui": "/display/TEST",
                "self": "INSTANCE_URL/confluence/rest/api/space/TEST"
            },
            "_expandable": {
                "metadata": "",
                "icon": "",
                "description": "",
                "retentionPolicy": "",
                "homepage": "/rest/api/content/1277954"
            }
        }
    ],
    "start": 0,
    "limit": 1,
    "size": 1,
    "_links": {
        "self": "INSTANCE_URL/confluence/rest/api/space?spaceKey=TEST",
        "base": "INSTANCE_URL/confluence",
        "context": "/confluence"
    }
}
...

Added an initial connection test action to this extension (which we can expand on when debugging this issue). If willing, mind installing this specific version:
pip install git+https://github.com/sphinx-contrib/confluencebuilder.git@introduce-connection-test

And then trying the following connection test from the Sphinx project (where conf.py resides):
python -m sphinxcontrib.confluencebuilder connection-test

I would be curious to see the raw results (although feel free to sanitize content such as the URL being used, if printed).

...but more so, it does not have the explicit Confluence data center version you may be using. If you maybe could scroll to the bottom of any Confluence page to indicate the major+minor version (e.g. v8.8), I can spawn up a matching version to compare (if the issue is related to the specific Confluence version).

sits at the end of each page

here is the output of python -m sphinxcontrib.confluencebuilder connection-test
Details

(sphinx) PS C:\code\sphinx-test\source> python -m sphinxcontrib.confluencebuilder connection-test
Fetching configuration information...
Running Sphinx v7.2.6
<module 'confluence' from 'C:\\code\\sphinx-test\\source\\confluence\\confluence.py'>

Sanity checks]
Checking that "confluence_server_url" is set... set.
Checking "confluence_server_url" value... good (HTTPS).
Confluence base URL: https://confluence.mycompany.com/
Confluence API endpoint: https://confluence.mycompany.com/rest/api
Checking that "confluence_space_key" is set... set.
Checking "confluence_space_key" value... looks good.
Checking proxy settings... no proxy configured.

Connection check]
Connecting to Confluence instance... DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): confluence.mycompany.com:443
DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/space?spaceKey=TEST&limit=1 HTTP/1.1" 200 None
could not find the configured space

(notice to debugging user)
Either ...

DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/search?cql=type%3Dspace+and+space.title~%22TEST%22&limit=2 HTTP/1.1" 403 None
failed to connect!
ERROR: Traceback (most recent call last):
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\cmd\conntest.py", line 292, in conntest_main
    publisher.connect()
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\publisher.py", line 107, in connect
    rsp = self.rest_client.get('search', search_fields)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 108, in _wrapper
    return func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 150, in _wrapper
    return func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 242, in get
    self._handle_common_request(rsp)
  File "C:\Users\me\.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 372, in _handle_common_request
    raise ConfluencePermissionError('rest-call')
sphinxcontrib.confluencebuilder.exceptions.ConfluencePermissionError:
---
Permission denied on Confluence (rest-call)

The configured user does not have permission to perform an action on the
Confluence instance. If the user should have access and this request is
using a personal access token, ensure the token is not expired/revoked.

(code: 403)
---

@Kugeleis, thanks for the information.
I have made more changes to the introduce-connection-test branch, if you want to update and retry the connection test. This primarily includes:

Using a simplified connection/space check at the start.
Reworked the use of confluence_publish_debug to dump full request/response URLs/headers/etc.

Maybe the new log changes will give better insight to the explicit headers being sent/received and provide some help.
Seems like you are using a custom variant of Confluence (which is fine)... just hard to know what specific version it was based on.
The only other thing that I could suggest you try (fishing here) is maybe changing the User-Agent field for requests (in the odd case where a server's front-end may not like this extension's value). For example, adding something like this:
confluence_publish_headers = {
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0',
}

update: we run on Confluence 7.19.17 (from the about page)

@Kugeleis, thanks for providing the explicit version of Confluence. Performed some testing today against that specific version of Confluence and I have not yet been able to produce the same connection issues you have been experiencing.
If you do not mind trying, I have made additional changes to the connection test, which you can upgrade using:
pip install -U git+https://github.com/sphinx-contrib/confluencebuilder.git@introduce-connection-test

And retrying the following command from your documentation's working directory:
python -m sphinxcontrib.confluencebuilder connection-test

Any information you can share from that run would be appreciated.
After a connection test run, another thing you can try is re-running the report request or documentation run using the "all" publish debug option that has been recently added. This should give you a raw inspection of the request made:
confluence_publish_debug = 'all'

Again, any information you can share from that output (which would require some more mindful sanitizing) would be appreciated. You are also welcome to Email me any results directly, if that helps.
At this time, I'm not sure what else to try off hand. The Confluence instance/gateway being interacted with is denying your requests (403). Maybe the publish debug run can reveal response headers indicating why the server is denying these requests. There has to be a specific reason why this is happening for your use case; and you may need to interact with the system administrator(s) of your instance to ask why this may be happening (ideally, they can see in their Confluence instance's log, reverse proxy log, etc. and see the explicit reason).

Here is the output with confluence_publish_debug = 'all' in conf.py (which doesn't seem to change an of the output).

output from python -m sphinxcontrib.confluencebuilder connection-test
Fetching configuration information...
Running Sphinx v7.2.6
<module 'confluence' from 'C:\Users\me\Programmieren\python\sphinx-test\source\confluence\confluence.py'>
Sanity checks]
Checking that "confluence_server_url" is set... set.
Checking "confluence_server_url" value... good (HTTPS).
Confluence base URL: https://confluence.mycompany.com/
Confluence API endpoint: https://confluence.mycompany.com/rest/api
Checking that "confluence_space_key" is set... set.
Checking "confluence_space_key" value... looks good.
Checking proxy settings... no proxy configured.
Connection check]
Connecting to Confluence instance... DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): confluence.mycompany.com:443
DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/space?spaceKey=TEST&limit=1 HTTP/1.1" 200 None
could not find the configured space
(notice to debugging user)
...
DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/search?cql=type%3Dspace+and+space.title~%22TEST%22&limit=2 HTTP/1.1" 403 None
failed to connect!
ERROR: Traceback (most recent call last):
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\cmd\conntest.py", line 292, in conntest_main
publisher.connect()
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\publisher.py", line 107, in connect
rsp = self.rest_client.get('search', search_fields)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 108, in _wrapper
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 150, in _wrapper
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 242, in get
self._handle_common_request(rsp)
File "C:\Users\me.virtualenvs\sphinx-test-n1Xk8596\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 372, in _handle_common_request
raise ConfluencePermissionError('rest-call')
sphinxcontrib.confluencebuilder.exceptions.ConfluencePermissionError:
Permission denied on Confluence (rest-call)
The configured user does not have permission to perform an action on the
Confluence instance. If the user should have access and this request is
using a personal access token, ensure the token is not expired/revoked.
(code: 403)

It looks to me that this recent test is using an older source, since I believe the logic that prints "notice to debugging user" was removed.

Here is the output with confluence_publish_debug = 'all' in conf.py (with a fresh venv).

output from python -m sphinxcontrib.confluencebuilder connection-test
Fetching configuration information...
Running Sphinx v7.2.6
<module 'confluence' from 'C:\Users\me\Programmieren\python\sphinx-test\source\confluence\confluence.py'>
Network-related configurations]
confluence_proxy: (not set)
confluence_publish_disable_api_prefix: (not set)
confluence_publish_headers: (not set)
confluence_publish_token: (set)
confluence_request_session_override: (not set)
confluence_server_auth: (not set)
confluence_server_cookies: (not set)
confluence_server_pass: (not set)
confluence_server_url: (set)
confluence_server_user: (not set)
confluence_space_key: (set)
Sanity checks]
Checking that "confluence_server_url" is set... good.
Checking "confluence_server_url" value... good (HTTPS).
Confluence base URL: https://confluence.mycompany.com/
Confluence API endpoint: https://confluence.mycompany.com/rest/api
Checking that "confluence_space_key" is set... set.
Checking "confluence_space_key" value... looks good.
Checking proxy settings... no proxy configured.
Connection check]
Connecting to Confluence instance...
(debug) Request]
GET https://confluence.mycompany.com/rest/api/space/TEST
User-Agent: Sphinx Confluence Builder
Accept-Encoding: gzip, deflate
Accept: /
Connection: keep-alive
X-Atlassian-Token: no-check
Authorization: Bearer 'NDA3verylongstringYVm'
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): confluence.mycompany.com:443
DEBUG:urllib3.connectionpool:https://confluence.mycompany.com:443 "GET /rest/api/space/TEST HTTP/1.1" 404 None
(debug) Response]
Code: 404
x-confluence-cluster-node: 123456703
x-confluence-cluster-node-name: confluence-production-1
set-cookie: JSESSIONID=AE9EF46E0554BE94DE2E35691F816E25; Path=/; Secure; HttpOnly, d013277e46556554677a8c9a2f41=128334343677753bc11f5ee8cbe5ca; path=/; HttpOnly; Secure; SameSite=None
cache-control: no-store
expires: Thu, 01 Jan 1970 00:00:00 GMT
x-content-type-options: nosniff
content-encoding: gzip
vary: User-Agent
content-type: application/json
transfer-encoding: chunked
date: Thu, 14 Mar 2024 13:00:10 GMT
failed!
ERROR: Traceback (most recent call last):
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\publisher.py", line 71, in connect
rsp = self.rest_client.get(f'space/{self.space_key}')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 109, in _wrapper
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 151, in _wrapper
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\rest.py", line 244, in get
raise ConfluenceBadApiError(rsp.status_code, errdata)
sphinxcontrib.confluencebuilder.exceptions.ConfluenceBadApiError:
Unsupported Confluence API call
An unsupported Confluence API call has been made. See the following
details for more information:
REQ: GET
RSP: 404
URL: https://confluence.mycompany.com/rest/api
API: space/TEST
DATA: {
"statusCode": 404,
"data": {
"authorized": false,
"valid": true,
"allowedInReadOnlyMode": true,
"errors": [],
"successful": false
},
"message": "No space found with key : TEST",
"reason": "Not Found"
}
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\cmd\conntest.py", line 302, in conntest_main
publisher.connect()
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\publisher.py", line 77, in connect
raise ConfluenceUnknownInstanceError(
sphinxcontrib.confluencebuilder.exceptions.ConfluenceUnknownInstanceError:
Unknown Confluence URL or invalid/restricted space detected
An issue has been detected when trying to communicate with the
configured Confluence instance. Ensure the instance is running and
inspect that the configured Confluence URL is valid:
https://confluence.mycompany.com/

If the instance is valid, ensure the configured space key and approriate
authentication permissions are configured.
               Space key: TEST
                Username: (empty)
   Password or API Token: (empty)

Personal Access Token (PAT):
Connection failure. Probing...
Will attempt to probe multiple API endpoints.
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): confluence.mycompany.com:443
Traceback (most recent call last):
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connectionpool.py", line 467, in _make_request
self._validate_conn(conn)
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connectionpool.py", line 1099, in _validate_conn
conn.connect()
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connection.py", line 653, in connect
sock_and_verified = _ssl_wrap_socket_and_match_hostname(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connection.py", line 806, in ssl_wrap_socket_and_match_hostname
ssl_sock = ssl_wrap_socket(
^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\util\ssl.py", line 465, in ssl_wrap_socket
ssl_sock = ssl_wrap_socket_impl(sock, context, tls_in_tls, server_hostname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\util\ssl.py", line 509, in _ssl_wrap_socket_impl
return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\AppData\Local\Programs\Python\Python311\Lib\ssl.py", line 517, in wrap_socket
return self.sslsocket_class._create(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\AppData\Local\Programs\Python\Python311\Lib\ssl.py", line 1108, in _create
self.do_handshake()
File "C:\Users\me\AppData\Local\Programs\Python\Python311\Lib\ssl.py", line 1379, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connectionpool.py", line 793, in urlopen
response = self._make_request(
^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connectionpool.py", line 491, in _make_request
raise new_e
urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\adapters.py", line 486, in send
resp = conn.urlopen(
^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\connectionpool.py", line 847, in urlopen
retries = retries.increment(
^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\urllib3\util\retry.py", line 515, in increment
raise MaxRetryError(_pool, url, reason) from reason  # type: ignore[arg-type]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='confluence.mycompany.com', port=443): Max retries exceeded with url: /rest/api/space?spaceKey=TEST&limit=1 (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)')))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 198, in run_module_as_main
File "", line 88, in run_code
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder_main.py", line 110, in
sys.exit(main())
^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder_main.py", line 50, in main
rv = conntest_main(parser)
^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\cmd\conntest.py", line 350, in conntest_main
conntest_probe(app.config)
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\sphinxcontrib\confluencebuilder\cmd\conntest.py", line 420, in conntest_probe
rsp = requests.get(
^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\api.py", line 73, in get
return request("get", url, params=params, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\api.py", line 59, in request
return session.request(method=method, url=url, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\sessions.py", line 589, in request
resp = self.send(prep, **send_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\sessions.py", line 703, in send
r = adapter.send(request, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\me\Programmieren\python\sphinx-test.venv\Lib\site-packages\requests\adapters.py", line 517, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='confluence.mycompany.com', port=443): Max retries exceeded with url: /rest/api/space?spaceKey=TEST&limit=1 (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)')))
Probing v1 (no-auth-no-headers)...

@Kugeleis, thanks for the detailed output.
Tried a couple more things and updated the connection test implementation again to help improve some scenarios.
Based on the provided output, there may be one thing that may be causing issues. In the example output, the initial request dump shows the following:
(debug) Request]
GET https://confluence.mycompany.com/rest/api/space/TEST
User-Agent: Sphinx Confluence Builder
Accept-Encoding: gzip, deflate
Accept: /
Connection: keep-alive
X-Atlassian-Token: no-check
Authorization: Bearer 'NDA3verylongstringYVm'

Specifically, the Authorization header has a bearer value that is wrapped in single quotes. However, testing in another setup using a PAT on a test instance, the "private" token value is not wrapped:
(debug) Request]
GET http://localhost:1990/confluence/rest/api/space/TEST
User-Agent: Sphinx Confluence Builder
Accept-Encoding: gzip, deflate
Accept: application/json; charset=utf-8
Connection: keep-alive
X-Atlassian-Token: no-check
Authorization: Bearer Nzk1MDk4NDM5ODAzOhdqxpxql02/xg5Jh8Kxwq/2J+MK

It could be that somewhere in the run scripts the value for the token confluence_publish_token is been wrapped with single quotes inside some double quotes; or maybe a CI script is passing in a token value set with a single-quote wrapped token (instead of just the token itself).
If you don't mind inspecting how the confluence_publish_token is set and seeing if you can produce a scenario where the bearer token is not single-quote wrapped, I would be curious to know the results. If it does work, I could then add additional configuration checks to help warn a user of such a state.

At this time, it is assumed that either the above suggestion may have helped, or an alternative approach has been made. Will close this bug. Feel free to comment to re-open if needed.


GEP: Enable cross namespace references from Routes

What would you like to be added:
This GEP attempts to tackle both cross namespace forwarding and route inclusion (proposed earlier by @stevesloka). These are closely related concepts that can likely be solved with the ReferencePolicy concept originally proposed by @youngnick.
Why is this needed:
Both cross namespace forwarding and route inclusion are common feature requests. ReferencePolicy provides a way to safely accomplish this. This is closely related to #411, #582, and #634.
Relevant docs include:

Gateway API Reference Policy
Selection Policy Proposal
Route Inclusion Proposal
Cross Namespace Forwarding Proposal

Note: Although the Gateway -> Route relationship is closely related to this discussion, I've decided to tackle that in a later GEP.

I'll take this one.
/assign


chore(backend): setup dancer2 backend for theweeklychallenge

This Pull Request closes #126 in https://github.com/manwar/TheWeeklyChallenge/issues/126) by introducing the complete setup for the Dancer2 backend for routes in https://github.com/manwar/TheWeeklyChallenge/issues/125.

Bootstrapped Dancer2 backend project.
Implemented MVC pattern structure.
Added controllers for Public routes.
Introduced 'Team' and 'User' models.
Integrated templates for Public routes.
Imported controllers modules in the main file.
Configured Dockerfile for backend containerization.
Added a Makefile for convenient command execution.
Implemented a .gitignore file to untrack unnecessary files.

These changes collectively enhance the Dancer2 backend, following MVC best practices and enabling containerization for efficient deployment.

Hello @manwar 👋
Here is a PR draft, I will be updating it as I'm progressing and promote it  as ready for review when I'm done

@baimamboukar I have a suggestion, keep the root namespace PWC::
I know the project is "The Weekly Challenge" then why "PWC"? It is because we started as "Perl Weekly Challenge". Even today we call the team "Team PWC"

@manwar

This is noted, and I will rename the project 🫡
The project has been initialized using the Dancer2 CLI, so the views folder is created automatically. I create the Models and Controllers directories inside the lib directory. Does this work for you, @manwar?

@baimamboukar "views" folder is the place for template if I am not wrong. The "Views" folder is backend code responsible for view part of MVC.

@baimamboukar "views" folder is the place for template if I am not wrong. The "Views" folder is backend code responsible for view part of MVC.

Yes @manwar. That's right
So we will have:

views for Templates (created by default with Dancer2 CLI)
Then the lib directory will contain the MVC pattern setup
Like..

lib
|_Models
|_Views
|_Controllers
Is it all good?

Hello @manwar 👋
This is ready for review

@baimamboukar There is some confusion and I must have misled you.
When I suggested PWC as root namespace I meant this:
  lib/Models/PWC/YourPackage.pm
  lib/Views/PWC/YourPackage.pm
  lib/Controllers/PWC/YourPackage.pl

Also when you name a package don't include word "Controller" or 'View" or "Model", the full namespace of the package makes it clear e.g. Controller::PWC::YourPackage

@baimamboukar There is some confusion and I must have misled you.
When I suggested PWC as root namespace I meant this:
  lib/Models/PWC/YourPackage.pm
  lib/Views/PWC/YourPackage.pm
  lib/Controllers/PWC/YourPackage.pm

Also when you name a package don't include word "Controller" or 'View" or "Model", the full namespace of the package makes it clear e.g. Controller::PWC::YourPackage

Noted @manwar ! I'm on it

Good job, thanks @baimamboukar

@baimamboukar I noticed you have everything under the "src/". I have moved everything out to the parent folder.

@baimamboukar I noticed you have everything under the "src/". I have moved everything out to the parent folder. I noticed you are not in the Slack. I have created separate workspace just for this project. You can join us there. Please share your email and I can send you invitation.

Thank you for your feedback, @manwar . I appreciate your input.

@baimamboukar I noticed you have everything under the "src/". I have moved everything out to the parent folder. I noticed you are not in the Slack. I have created separate workspace just for this project. You can join us there. Please share your email and I can send you invitation.

Oooh! Sorry... The link was broken when I tried to join....
You can send the invitation to<EMAIL_ADDRESS>Thanks @manwar 🫡✨

@baimamboukar sent the invitation.


feat: support go modules

Have you given supporting go modules any thoughts?

@simt2 Thanks for the Pull Request. Looks good.
Go mod support will be included with the next release.

Awesome @go-jet , feel free to close the PR, I guess you'll be working on this in a branch of your own. Just fyi, the installation procedure in the README is broken and could be fixed with proper module support.

@simt2 I'll merge the change into new branch.
Could you open a separate issue for installation problems you encountered.


IAdapaterIntegration availability

I want to develop a bot targeting Telegram and I would like to create my own adapter as shown in the console bot sample but I also want to fit in the standard process defined in other samples that use UseBotFramework method.
After searching in code, I've seen that it get an instance of adapter that implements IAdapterIntegration from dependency injection.
This interface had been added 11 days ago, some days after the last release (15 days ago).
When the next release is planned in order I use this interface for my adapter?
Regards

Hi @nimbusparis!
The myget feed here has all the daily releases! Chances are high that if the interface was added, it will be in the daily releases there.

@nimbusparis
We hope to be getting 4.1 on the NuGet feed today. This should include this interface and the related dependency injection.


chore: fix inconsistency for notify code sample

Closing due to the fact that the examples are being changed completely by replacing it with gm-hackers.


Need of a Canteen loader

An animated cooking loader will be integrated during the loading of the website

Assign me the task

Update of your Task?

Its almost complete. Will create the PR by tonight


Handle single bit conditions in QPY

Summary
In #6018 initial support for adding classical conditions on a single bit
instead of a register was added. However this wasn't accounted for in
qpy because it didn't exist when qpy was first written. This commit adds
support to qpy without a file format change so it can be backported and
used with already released versions of qpy without needing a new format
version. This is accomplished by exploiting the strict register naming
in qiskit. A register can't have a name outside of regex
"[a-z][a-zA-Z0-9_]*" which we leverage in the case of single clbit
conditions the "register" name in the output QPY data is set to
str(clbit_index) which isn't a valid name. Then on the loading side we
check for a valid name, if it's outside the allowed regex we treat the
condition as a single bit and the name is a str(index). The tradeoff here
is that for a QPY file generated with 0.18.1 (assuming this is backported
and included in 0.18.1) containing single bit conditions this qpy file can not be loaded with qiskit
0.18.0. But this is fine as we only guarantee compatibility in one
direction (loading qpy files generated with older with qiskit with a
newer version of qiskit).
Details and comments
Fixes part of #6475

This seems like an emminently sensible way of doing things with the aim being to maintain as much backwards comaptibility with 0.18.0 with as little additional stuff as possible.
Is it worth considering allowing ourselves to take the process further, without breaking the ability to read and write older formats?  We can effectively pack as much metadata as we like in by having the first byte be a sentinel invalid identifier character (say \ or whatever), and follow it with an addtional packed structure.  We only need emit this in _write_instruction (or similar) if we're using newer features, so older versions will still be able to open the files if they're not in use.
I don't know how much effort we want to put into maintaining the compatibility, though. This is obviously a very hacky suggestion, and it'd be better to account for it directly in the instruction struct, if we're not bothered about losing ABI compatibility for all circuits.

Yeah, I feel like we should really only do this once since it's kind of hacky and I don't want to have to deal with negotiating different undocumented string formatting for metadata across versions. I opted for this here only because QPY was first released in 0.18.0 and this is something we can backport for 0.18.1 without breaking compat. If we were further away from 0.18.0 and unlikely to push a bugfix release I'd probably just opt to do this in a QPY v2 format and tweak the instruction struct. That being said my feeling here is that unless there is some clear case of something missing from the representation of conditionals in this PR I'd rather not make it more clever than needed. If in the future we add new features on conditions I'd agree we should add a V2 format and change the instruction struct (or create a new condition struct and embed that into the instruction) to represent that extra metadata. We have the qpy format versioning to enable representing new features across release boundaries for this reason (it's just not something we can/should backport to a bugfix release).
That being said I like your idea of prefixing the index int string with a null character. That seems less error prone and does technically leave us open to adding additional prefixes to represent different things if needed. (the int index string does limit this potential future use).

Ah, I didn't know that the QPY format was only in 0.18.  If that's the case, before it gets any further, would it be better to use the Qiskit version section of the header struct to store the minimum version of Qiskit which would be able to load the file, rather than the version which created it?  That lets us "inject" the backward compatibility into the format: newer versions of Qiskit have complete knowledge of older versions, but an older version doesn't know what the latest version it can support is.  That way, the deserialiser can just check if its version is compatible with the stored minimum version, and reject the input cleanly if not.  If we've never released a new version of Qiskit since, we have an opportunity to make this change without breaking any compatibility.
I'd be happy to tick this now if you want to leave it as-is.  I'm also happy waiting if you're changing it to use the null byte and a slightly more defined way of adding more metadata, or if you want input from people with a bit more experience than me!

Well that's actually kind of how it's used today. We only have a guarantee for loading a qpy file from the qiskit release that generated it forward, loading it with an older version of qiskit may work but is unsupported. The qpy_serialization.load() function actually emits a warning if qpy.qiskit_version is > qiskit.__version__: https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/circuit/qpy_serialization.py#L979-L984

I think I mean something slightly different: say in this case, we know that a file generated by 0.18.1 will be successfully loaded by 0.18.0 in some cases and not in others, however at generation time, 0.18.1 knows whether it's using any features that 0.18.0 doesn't support.  I'm proposing that instead of storing 0.18.1 in the header in this case, we store 0.18.0 if we don't use anything incompatible.  That way 0.18.0 doesn't need to speculatively attempt the load (which, if we're unlucky, will silently "succeed" but be doing the wrong thing), it can know whether it supports the file.  It'd let us upgrade the warning to an error, without limiting the forwards spec.

The write function would change from https://github.com/Qiskit/qiskit-terra/blob/265530145033bc31a92fc6989be1e5e20de92252/qiskit/circuit/qpy_serialization.py#L856-L868
to something approximately like
    minimium_version = (0, 18, 0)
    output = io.BytesIO()
    for circuit in circuits:
        minimum_version = max(_write_circuit(output, circuit), minimum_version)
    header = struct.pack(
        FILE_HEADER_PACK,
        b"QISKIT",
        1,
        *minimum_version,
        len(circuits)
    )
    file_obj.write(header)
    output.seek(0)
    file_obj.write(output)
    output.close

where _write_circuit (and subsiduary functions) now returns the minimum feature version it's used.

Ah, I see what you were getting at now. I'm not sure it's worth the effort though, especially in this case it's a pretty esoteric edge condition. Someone has to be running 0.18.1 to generate qpy and load it with 0.18.0. The only difference between this without that change is when they do that it will raise a warning, which doesn't seem like a big deal IMO. Especially as at least I would prefer to discourage people from trying to go backwards when loading qpy.

That's fair.  I was thinking more for the future (say Terra 0.20 producing a very simple circuit that 0.18 could still load), but as you say, it's probably too much effort to worry about.

Since building circuits with single-bit conditionals was not formally "released" in 0.18, is this urgent/requiring a backport? If not, and given that it looks like there will be further changes to the conditional formats coming soon ( #6761 ) that likely will need a file format change, does it might makes sense to introduce this now as an additional case that will live on in the loader?

That's a good point, I don't know if it's urgent. I put this together because @taalexander went to use a single clbit condition and serialize it with qpy and hit an error. So there is at least 1 person who tried it. I weighed that against the extra 10-15 lines (although it was more like 2 in the original incarnation of the patch) we'd have to carry around in the V1 format reader and figured it was worth it. But I don't feel super strongly about that.

@kdk I added a note to the release note about the single clbit condition feature not being supported yet in: https://github.com/Qiskit/qiskit-terra/pull/6775/commits/4246c1981cbb6858c2f3aae93dd735ef584732dd

@kdk are we happy to merge this now?  It's one of only a couple of PRs left blocking 0.18.1.


Fix 500 on resources endpoint

It was a little tricky to write the test for this, or at least tricky to do without getting distracted by other things.
Fixes https://github.com/ansible/django-ansible-base/issues/183

I don't really care about the missing coverage here, because it's logging and other stuff when it doesn't work.


⚠ BCR Bot has degraded performance

In f30ed51, BCR Bot (https://bcr.alternativasinteligentes.com/BCRApi/web/chatbot) experienced degraded performance:

HTTP code: 200
Response time: 1122 ms

Resolved: BCR Bot performance has improved in 67b78a6.


chore(docs): Added gemini, together, openrouter and local models integrations to docs

Given our native support of OpenAI SDK and many companies supporting that format by default, as per slack discussion, added a few pages that outline how Weave can be utilized with those companies even before we have a native integration with their pytho clients.
Also added a local models category, with links to the most popular local model runners with support for OpenAI SDK
(Attempt number 2, PR #1909 failed on CLA because I had a misconfigured git email on my machine)
Signed-off-by: Alex Volkov<EMAIL_ADDRESS>

I have read the CLA Document and I hereby sign the CLA


LineMarkerInfo deprecated for rubymine 2022.2

Description

Steps to Reproduce
I don't really know how to reproduce, it seems to happen when RubyMine start.
Expected behavior: No error
Actual behavior: Getting an error message at each RubyMine start
Versions

RubyMine 2022.2
Build #RM-222.3345.111, built on July 25, 2022
Ember.js plugin: 2016.1.4-0
Additional Information
None

v2016.1.4 of the plugin is not meant to be used with v2022.2 of RubyMine. you might want to wait until we've released a version that is compatible :)

fixed by https://github.com/Turbo87/intellij-emberjs/releases/tag/v2022.2.1


Set up a decent frontend that also displays the library version

The url input and detection feedback is presented in a clearer manner.
Additionally the library version is displayed in a header of what is displayed on the site

The total work will be reviewed on the dev branch as the current branches are related


Can the continous transformer autoregressive wrapper help with pre-training on time-series data?

Your work is an incredible resource for transformer architectures. They are well worn in the NLP domain and I have noticed their increase use with time-series.I have however also noticed a dearth of code and tools to pull from when applied to time-series.
I would be interested to try all the interesting goodies available on my time-series datasets, in particular pre-training and subsequent fine-tuning. How would one best go about it, if it is at all possible with the continous transformer?

@Espritdelescalier Hey! So the truth is time series is one domain that transformers still struggle with (tabular data being the other)
You would be better off going with N-Beats if you are in industry and want something off the shelf. However, if you are a PhD student looking to see if attention can win in this arena, I would recommend starting with this baseline and then working your way up

@Espritdelescalier you should try https://github.com/lucidrains/Mega-pytorch for time series

We have had some success with transformers for time series: https://arxiv.org/abs/2208.14236

@Froskekongen very cool! this looks promising as well https://arxiv.org/abs/2211.14730
getting closer..

@Espritdelescalier  https://arxiv.org/abs/2211.14730


is ip address validator implemented successfully

@kheeedr reaname test/rules/it/is_ip_address.dart to test/rules/it/is_ip_address_test.dart
so flutter can run the tests


[zh] Sync content secret file

[zh] Sync content secret file: content/en/docs/concepts/configuration/secret.md
related: #27672

/lgtm


I'm facing problems while running version 7.0.0+2 example.

When trying to run the example, I encountered errors like:

Target of URI hasn't been generated: 'package:example/src/components/example_registrar.g.dart'.
Target of URI hasn't been generated: 'package:example/src/dotted_border_builder.g.dart'.
Target of URI hasn't been generated: 'package:example/src/svg_builder.g.dart'.

After commenting out the problematic code blocks, I encountered a different error.

@vpsdeveloper
strokeAlignCenter was added 4 months ago to the Flutter so maybe some old version of Flutter you have and generated code is not valid for supported Flutter version
@jpeiffer What version of Flutter is needed to have in order to validly built that project
I have Flutter (Channel stable, 3.13.3) and also some issues with generation
ERROR: ../lib/src/builders/json_floating_action_button_builder.g.dart:104:26: Error: Couldn't find constructor '_DefaultHeroTag'.
json_floating_action_button_builder.g.dart:104
ERROR:     this.heroTag = const _DefaultHeroTag(),
ERROR:                          ^^^^^^^^^^^^^^^
ERROR: ../lib/src/builders/json_floating_action_button_builder.g.dart:416:26: Error: Couldn't find constructor '_DefaultHeroTag'.
json_floating_action_button_builder.g.dart:416
ERROR:     this.heroTag = const _DefaultHeroTag(),
ERROR:                          ^^^^^^^^^^^^^^^
ERROR: lib/src/export_example_page.dart:56:30: Error: Too many positional arguments: 0 allowed, but 1 found.
export_example_page.dart:56
ERROR: Try removing the extra positional arguments.

ERROR:               title: JsonText('Example'),
ERROR:                              ^

For example it is constructing the code from internal value as the default - and because of that the generated file is invalid

The generator runs via Flutter 3.13.  If you need the generated files in addition to the source, you can download them from pub.dev here.
If you need to compare, you can use that to compare to what you're seeing locally.  The published generated files from from the stable branch at build time using a Linux build agent.

@jpeiffer Isn't it a bug that generator tries to use _DefaultHeroTag private field as default value?

Oh, this is on JSON generation from Dart and not generating the Dart code itself?  If so, can you provide the full Dart code you are trying and I can try it out?

Ok after upgrading mine code and the Flutter everything is building fine - so issues solved for me :)

I'm going to assume this can be closed.  If the issue persists, feel free to re-open or create a new one with additional details.


Bug when building HTML

Hi!
I encountered and issue while building Sphinx with GLPI theme, when I follow the readme instructions.
Actually the issue comes from the fact that spinx_glpi_theme.get_html_themes_path() returns a list, thus html_theme_path = [sphinx_glpi_theme.get_html_themes_path()] is a nested list.
It is fixed if one uses instead:
html_theme_path = [*sphinx_glpi_theme.get_html_themes_path()]
#or
html_theme_path = sphinx_glpi_theme.get_html_themes_path()

Here is my log:
# Sphinx version: 3.0.1
# Python version: 3.7.3 (CPython)
# Docutils version: 0.16 release
# Jinja2 version: 2.11.1
# Last messages:

# Loaded extensions:
Traceback (most recent call last):
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/cmd/build.py", line 279, in build_main
    args.tags, args.verbosity, args.jobs, args.keep_going)
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/application.py", line 277, in __init__
    self._init_builder()
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/application.py", line 332, in _init_builder
    self.builder.init()
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/builders/html/__init__.py", line 219, in init
    self.init_templates()
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/builders/html/__init__.py", line 257, in init_templates
    theme_factory = HTMLThemeFactory(self.app)
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/theming.py", line 162, in __init__
    self.load_additional_themes(app.config.html_theme_path)
  File "/home/titus/.local/lib/python3.7/site-packages/sphinx/theming.py", line 173, in load_additional_themes
    abs_theme_path = path.abspath(path.join(self.app.confdir, theme_path))
  File "/usr/lib/python3.7/posixpath.py", line 94, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib/python3.7/genericpath.py", line 149, in _check_arg_types
    (funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'list'

Best!

Will fix, thank you


Monotonic time, fix sendfile tests, add more timing&size metrics

So I started with monotonic time and then changed a few other things too :D. I'll be happy to break this up to individual commits.
Timing metrics:
request_start
    headers_start
    ...headers parsing...
    headers_end

    body_start
    ...body parsing...
    body_end

    user_start
    ...callback code...
    user_end

   send_start
   ...sending reply....
   send_end
request_end

Also added response size metrics in bytes:
resp_headers
resp_body  %% regualar response body size
file  %% sendfile response size
chunks %% all chunks size (wire size), not equal to Content-Length!

I've changed files handling - now ranges/content-size handled by Elli.
Fixed sendfile tests (looks like migration to new rebar broke them?)
Added tests for timing & size metrics.

Looks like erlang:monotonic_time/0 is 18+. I'd be inclined to drop support for <18 rather than add a patch. @elli-lib/team?

I'm not sure why this failed on Travis. Works for me locally on 19.0.5.

Personally I'd vote for dropping OTP<18.

Can you comment out - 17.5 in .travis.yml then too?

Added docs, commented 17.5

Hey, can you regenerate the docs again?
I made minor grammar tweak in https://github.com/elli-lib/elli/pull/10/commits/a072aed50a759bb23da286eaf4242ac3a02e5e42. It's cool if you want to do rebar3 doc then squash/ the last two commits.

Actually we should do a version bump, maybe to 1.2.5.

done

Awesome, thanks!
Close #7 and close #8.


Wv1

Instructions: (please delete)

please do not submit against master, use develop instead
please make sure there is an associated issue for your PR, and reference it via "Fixes #num" in the description
please enter a detailed description

.patch to end of URL

Some crypto bro trying to inject code into the README. 🙄


Mouse codes are printed to the terminal on exit

Sometimes mouse codes are printed to the terminal on exit. This tends to occur if you are moving the mouse around then exit quickly.
I suspect this is because the app exists prior to all mouse events in stdin being consumed.
Find a way to a) reliably reproduce this error and b) fix it.
I suspect this will require disabling input then posting a null event and waiting for that event to be processed, prior to exiting.

I wonder whether PyAutoGUI could be used as part of this? Have a test wiggle the mouse and then ctrl-c the app? Though then you'd have to spawn the app somewhere and then run the test in a separate process/window/etc

@willmcgugan I'd like to take a shot at this

My programing skills are not intermediate yet but I am a daily linux user. I'd like to try my hand at this, after recreation of the issue I would attempt to turn the unwanted mouse output into a daemon with the subprocess module

My thinking is that this would require a shutdown routine for the event loop. In that routine we would use termios.tcflush() or similar to flush stdin before we exit. For Windows we would need to use mscrt to read keys - not sure if that will translate to mouse events though.

Should be fixed in 0.1.13

Should be fixed in 0.1.13


RELATED: RAIL-2407 Integrate catalog export with boilerplate

JIRA: RAIL-2409

Build succeeded (gate pipeline).

https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-merge-compliance-check/39/ : SUCCESS in 12s
https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/111/ : SUCCESS in 36s
https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-fossa-scanning-zuul-el7/4/ : SUCCESS in 2m 44s (non-voting)


Support in.tftpd and gdb debugging in qemu

These are not really related, but they were sitting in my repo when I started to update to latest upstream.  I figured I clean them up and send upstream.

I have updated, not sure if you like the style but it seems to work ok.

LGTM! Will just wait for CI to confirm things are still working and then I'll merge.


Relicense to dual MIT/Apache-2.0

This pull request was automatically generated because my scripts detected that
everyone in the relicensing issue agreed to
relicensing.
License headers in files were not updated, if they exist. I've reproduced an
example license header below if you want to copy-paste it in. If you don't
have license headers, don't feel compelled to add
them.
// Copyright 2016 static-server Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

I recommend publishing a new patch version (the z in x.y.z) so that the
metadata propagates to crates.io.
Please be sure to check the README.md for style. I've try to
review these PRs as they go out, but I might miss something.
Thanks for relicensing!
(For my bookkeeping: this is repository id static-server-ca1fa7bf-8351-462d-a3af-6f5ee4b45c43)

I've done it manually.


Any possibility of supporting transpose operation?

According to https://coral.ai/docs/edgetpu/models-intro/#supported-operations coral does not seem to support Transpose op. I would presume that under some limiting circumstances (e.g., not transposing batch dim, etc.) the device should be able to support this. And the operation would be very helpful -- given size limitations, using grouped convolutions might be an easy way to get better accuracy. However, such architectures usually involve a channel "shuffle" so that channels from different groups can get mixed and such shuffle is usually implemented by reshape + transpose + reshape.

+1

Hi guys, I do have a feature request opened for this internally, will keep update if we move forward with it.

For any one face this issue
by converting pytorch to keras (not tensorflow) i was able to fully convert my model to NHWC and by that avoiding the TRANSPOE nodes, edge tpu comile was able to map all operations to TPU  (:

+1, badly need this feature

Compiler version 16 supports 'Transpose' operations. Please see the list of supported operations at https://coral.ai/docs/edgetpu/models-intro/#supported-operations.


operator project-quay (3.11.5)

Add 3.11.5 to community operators

/merge possible

/merge possible