Python 访问 GitLab 的脚本在 Windows 上运行,但 returns 'Project Not Found' 在 Windows 子系统上运行 Linux (WSL) - 使用 python要求

Python script which access GitLab works on Windows but returns 'Project Not Found' on Windows Subsystem for Linux (WSL) - Used python requests

我有一个 python 脚本,它向 GitLab 发出 GET 请求,并使用 tablib 将响应中的数据存储在 excel 文件中图书馆。

当我使用 python3.

执行此脚本时,它在 Windows 中运行良好

我已尝试在 Windows 子系统中为 Linux (WSL) 执行相同的脚本,但脚本失败了。

我在 WSL 中使用 python3 script.py 执行时的输出如下:

RESPONSE {"message":"404 Project Not Found"}

当我使用 python .\gitlab.py 从 Windows 执行时,其中 pythonpython3:

RESPONSE [{"id":567,"iid":22}, {"id":10,"iid":3}]

我认为问题可能与我正在执行的 GET api 调用有关,因为在 WSL 中 returns 未找到项目。

我在 WSL 中使用 curl 执行了该请求,以查看 unix 通常是否存在此问题,但我得到了预期的响应,而不是未找到的响应。这是请求:

curl -X GET   'https://URL/api/v4/projects/server%2Fproducts%2FPROJECT/issues?per_page=100'   -H 'Content-Type: application/json' -H 'PRIVATE-TOKEN: TOKEN' --insecure

如果 unix 能够使用 curl 执行获取请求,为什么 python 在 unix 中使用 Python 失败?我应该 enable/disable 在请求中添加一些东西吗?

这是我在 python 脚本中执行的请求:

def get_items():

    url = "https://URL/api/v4/projects/server%2Fproducts%2FPROJECT/issues"

    payload = {}

    querystring = {"state": "closed", "per_page": "100"}

    headers = {
        'Content-Type': "application/json",
        'PRIVATE-TOKEN': os.environ.get("GITLAB_KEY") # enviromental variable added in windows 
    }

    requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

    response = requests.request(
        "GET", url, headers=headers, data=payload, params=querystring,  verify=False)

    print("RESPONSE " + response.text)
    return json.loads(response.text)

更新:

我也尝试过使用项目 ID 而不是路径,但没有成功

REF:https://docs.gitlab.com/ee/api/projects.html#get-single-project

获取/项目/:id

改变这个: url = "https://URL/api/v4/projects/server%2Fproducts%2FPROJECT/issues" 到 projectId = 1234 # 或者你的项目 ID 是什么...项目页面,设置 -> 常规 url = "https://URL/api/v4/projects/" + projectId + "/issues"

根据我在 Reddit 上 post 得到的答案,我发现了问题。

在 python 脚本中,我使用了一个无法从 WSL 以这种方式 (os.environ.get("GITLAB_KEY") ) 访问的环境变量。

目前,我已将其替换为硬编码值,只是为了检查这是否确实是问题所在。该脚本现在按预期运行。

既然我知道问题出在哪里,我会想办法再次访问环境变量。