10
9
Fork
You've already forked linux-app
14

pygobject upper version #634

Closed
opened 2025年04月20日 20:16:13 +02:00 by gothicVI · 4 comments

Is there an option to loose the upper version pinning on pygobject?
3.52.3 has been released but can't be used due to the constraint - also Debian 12 is out for some time already.

Generally, specifying upper version bounds leads to more problems than simply fixing the very rarely occurring ones due to potential breaking changes.

Is there an option to loose the upper version pinning on `pygobject`? `3.52.3` has been released but can't be used due to the constraint - also Debian 12 is out for some time already. Generally, specifying upper version bounds leads to more problems than simply fixing the very rarely occurring ones due to potential breaking changes.

Debian 12 does not have libgirepository-2-0-0: https://packages.debian.org/search?keywords=libgirepository-2.0

unless I am looking wrong?

I want the client to still work if someone pip installs. Ideally pygobject could look if the system has libgirepository 1.0 or 2.0

any ideas how I can fix this without specifying an upper version?

Ughhh python packaging is such a huge mess

Debian 12 does not have libgirepository-2-0-0: https://packages.debian.org/search?keywords=libgirepository-2.0 unless I am looking wrong? I want the client to still work if someone pip installs. Ideally pygobject could look if the system has libgirepository 1.0 or 2.0 any ideas how I can fix this without specifying an upper version? Ughhh python packaging is such a huge mess

Debian 12 does not have libgirepository-2-0-0: https://packages.debian.org/search?keywords=libgirepository-2.0

unless I am looking wrong?

No, you're right.

I want the client to still work if someone pip installs. Ideally pygobject could look if the system has libgirepository 1.0 or 2.0

I guess if the proper version of libgirepository isn't installed then the dependency does not install.

any ideas how I can fix this without specifying an upper version?

I think the upper version is not needed at all. It only hinders people who could use a higher version to install it. Correct me if I'm wrong but I don't see what pinning the upper version gives us.

Ughhh python packaging is such a huge mess

Agreed ;)

> Debian 12 does not have libgirepository-2-0-0: https://packages.debian.org/search?keywords=libgirepository-2.0 > > unless I am looking wrong? No, you're right. > I want the client to still work if someone pip installs. Ideally pygobject could look if the system has libgirepository 1.0 or 2.0 I guess if the proper version of `libgirepository` isn't installed then the dependency does not install. > any ideas how I can fix this without specifying an upper version? I think the upper version is not needed at all. It only hinders people who could use a higher version to install it. Correct me if I'm wrong but I don't see what pinning the upper version gives us. > Ughhh python packaging is such a huge mess Agreed ;)

I guess if the proper version of libgirepository isn't installed then the dependency does not install.

Yes and the the client doesn't install at all

Try e.g.

pipx install "eduvpn-client[gui]==4.4.0"

It will fail with Dependency 'girepository-2.0' is required but not found

4.5.0 works fine due to the pinning to the upper version.

I think the upper version is not needed at all

It is, otherwise the newest version is automatically being pulled in, which requires libgirepository 2.0

> I guess if the proper version of libgirepository isn't installed then the dependency does not install. Yes and the the client doesn't install at all Try e.g. ``` pipx install "eduvpn-client[gui]==4.4.0" ``` It will fail with Dependency 'girepository-2.0' is required but not found 4.5.0 works fine due to the pinning to the upper version. > I think the upper version is not needed at all It is, otherwise the newest version is automatically being pulled in, which requires libgirepository 2.0
pipx install "eduvpn-client[gui]==4.4.0"

That doesn't work as there is no option gui . But I get where you're going.

It is, otherwise the newest version is automatically being pulled in, which requires libgirepository 2.0

I totally overlooked that. You're right! What about adding an option [libgirepository1] that pins the dependency and have the regular version pull the latest version?

> ```bash > pipx install "eduvpn-client[gui]==4.4.0" > ``` That doesn't work as there is no option `gui` . But I get where you're going. > It is, otherwise the newest version is automatically being pulled in, which requires libgirepository 2.0 I totally overlooked that. You're right! What about adding an option `[libgirepository1]` that pins the dependency and have the regular version pull the latest version?
Sign in to join this conversation.
No Branch/Tag specified
master
upstream-deb
openvpn-persistent
1.x
4.7.2
4.7.1
4.7.0
4.6.0
4.5.1
4.5.0
4.4.99.0
4.4.0
4.3.1
4.3.0
4.2.99.1
4.2.99.0
4.2.1
4.2.0
4.1.99.0
4.1.3
4.1.2
4.1.1
4.1.0
3.1.1
4.0.1
4.0.0
pr-3.3.1
pr-3.3.0
pr-3.2.0
3.1.0
3.0.0
2.2.1
2.2.0
2.1.0
2.0.0
1.1
1.0.3
1.0.2
1.0.1
1.0rc17
1.0rc16
1.0rc15
1.0rc14
1.0rc13
1.0rc12
1.0rc11
1.0rc10
1.0rc9
1.0rc8
1.0rc7
1.0rc6
1.0rc5
1.0rc4
1.0rc3
1.0rc2
1.0rc1
0.8
0.7.2
0.7.1
0.7
0.6.1
0.6
0.5.1
0.5
0.3
0.2.1
0.2
0.1.1
0.1
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
eduVPN/linux-app#634
Reference in a new issue
eduVPN/linux-app
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?