Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux Packaging #90

Closed
acxz opened this issue Jul 21, 2019 · 10 comments
Closed

Linux Packaging #90

acxz opened this issue Jul 21, 2019 · 10 comments

Comments

@acxz
Copy link
Contributor

acxz commented Jul 21, 2019

Feature

It would be great to have gtsam as a GNU/Linux package.

Motivation

Being able to sudo apt install gtsam will make it easy to install and develop on the gtsam library. Building from source does take a significant amount of time and is tedious. Having a precompiled package on for example, https://launchpad.net/, will speed this up and allow the development group to be more in control of the release versions available to the users.

Pitch

Have packages for widely available GNU/Linux distributions, such as Debian, Ubuntu, etc.
EDIT: There is a gtsam package maintained by the community for Arch Linux already here.

Alternatives

N/A

Additional context

N/A

@jlblancoc
Copy link
Member

jlblancoc commented Jul 22, 2019

Hi,
Do you mean... this? ;-)

PS: Though, it's not 100% ready to be released as an official Debian package, it should be split into, at least, libgtsam and libgtsam-dev, etc. but whoever is interested, could take on the work at the current point.

@acxz
Copy link
Contributor Author

acxz commented Jul 22, 2019

Ah I see, it seems like I did not search hard enough. Maybe having the Linux packages available on the gtsam website (under Getting started or Build) would be a good idea for visibility.

In addition to the nightly release builds for Ubuntu builds, it would be nice to have the latest stable versions on the PPA. Also as you mentioned the current packaging does not conform to the Linux Filesystem Hierarchy Standard, which would be necessary for a Debian package instead of a community build on Launchpad.

So I guess these 3 things would be nice to have:

  1. Visibility of Linux Packages on GTSAM website
  2. Stable Releases on Launchpad
  3. Conform Debian-based packages to the Linux FHS

@dellaert
Copy link
Member

I fully support you both providing all of the above :-) GTSAM website is also in a repo and open to PR's, just Github Pages based...

@varunagrawal
Copy link
Collaborator

Maybe consider a snap instead of a deb package?

@dellaert
Copy link
Member

Why?

@varunagrawal
Copy link
Collaborator

varunagrawal commented Jul 30, 2019

Snaps are universal so they are not restricted to any particular distribution, unlike deb packages which are restricted to Debian based distributions. Plus more recent distros come equipped with the snap command line tool.

As a side, I am personally of the opinion that Linux packaging is a mess due to its being so opinionated. I prefer having a Homebrew based installation especially since Homebrew now supports Linux and Mac by default.

@acxz
Copy link
Contributor Author

acxz commented Aug 3, 2019

I have my own reservations on snaps and personally prefer traditional Linux packaging. Also in regards to Homebrew, I believe vcpkg is better in this aspect since it also supports Windows.

All in all tho, I believe software developers, such as the GTSAM group, should not worry about packaging at all. The onus is on the respective community (whether it be the homebrew community or individual Linux distro communities) to go from a source install to the package. If there is a need in said community, the community will create the package. It is just that packaging helps raise visibility of software and a package meshes better with an operating system than source installs. This is usually the reason why development groups will at least officially support one form of packaging (preferably a popular one such as Debian, whose software package repos are used by many Debian derivatives including Ubuntu).

@varunagrawal
Copy link
Collaborator

@jlblancoc I believe you've already done this? Can we close it?

@dellaert
Copy link
Member

@jlblancoc if you bieve this has been addressed we'll let you close.

@jlblancoc
Copy link
Member

Well... I would say it's sort of done, in the practical sense, since anyone can quickly install gtsam right now from the PPA in seconds for any architecture (arm64, ...).

Now, it remains an open issue the proper packaging for, for example, Debian (Ubuntu), which would require more work. But normally these things are handled by different people than those working "upstream", so... yes, I'll close this one, and if proper packaging requires changes upstream someday, let new issues to be open for that.

varunagrawal added a commit that referenced this issue Apr 17, 2021
b80bc63cf Merge pull request #90 from borglab/fix/tpl_dependency
015b12da5 Merge pull request #86 from borglab/feature/optionalargs
362851980 address review comments
e461ca50e Merge pull request #89 from borglab/fix/template_iostream
2d413db57 add pybind cpp generation dependency on tpl file
79881c25e include pybind11 iostream for ostream_redirect in example tpl
5e8323c25 fix test fixture
95495726a Merge branch 'master' into feature/optionalargs
5af826840 clean up the _py_args_names method to reduce copy-pasta
844ff9229 add identifier parsing to _type
c3adca7a4 remove extra spaces from Type repr
350b531d7 slight test improvement
fd4f37578 cleaner default argument parsing
6013deacb overpowered default argument parsing rule
dbcda0ea2 fix unit tests for __repr__ ref  vs ptr
1c23c42e4 fix pointer vs const ref in __repr__
9b40350f1 update matlab tests
df7e9023c handle __repr__ with default arguments
092ef489b update pybind_wrapper for default arguments
3a2d7aa8a unit test default argument pybind
61a2b114e implement default argument parser
c2b92ffec unit test for parsing default arguments

git-subtree-dir: wrap
git-subtree-split: b80bc63cf466f9751e8059c0abb4a4d73b23efbe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants