Skip to content

geotrans/3.8#6512

Merged
conan-center-bot merged 18 commits intoconan-io:masterfrom
samuel-emrys:recipe/geotrans
Oct 15, 2021
Merged

geotrans/3.8#6512
conan-center-bot merged 18 commits intoconan-io:masterfrom
samuel-emrys:recipe/geotrans

Conversation

@samuel-emrys
Copy link
Copy Markdown
Contributor

@samuel-emrys samuel-emrys commented Jul 26, 2021

Specify library name and version: geotrans/3.8

I saw that there was an outstanding library request for it (#1779). I wanted to learn about conan packaging and this looked like a good candidate, since I also wanted to check the library out. I'm not the author of this library.

One of the hook tests is currently failing. I've raised #6511 for discussion of this issue and an appropriate way forward. I figured it deserved it's own issue as it raises questions about the assumptions of the "no imports" test more generally than just this package.

closes #1779


  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the
    conan-center hook activated.

* Add CMakeLists.txt to build geotrans library
* Add CCI package configuration
* Add functional test package using geotrans library provided sample
  code
* Build both libMSPdtcc and libMSPCoordinateConversionService to remain
  consistent with the upstream package. This is a change from the
  previous state in which both of these libraries were bundled into one.
* Remove extraneous comments from test_package conanfile
* Remove extraneous print statements from test_package example.cpp
* Add component definitions to package_info. This will allow cmake
  utilities like find_package to search for and find the package and its
  component libraries, which will enable linking against these
  individually for more granular control.
* No longer a shared library by default
* Update homepage metadata
* Update URL metadata
@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Jul 26, 2021

CLA assistant check
All committers have signed the CLA.

@conan-center-bot

This comment has been minimized.

@ruilvo
Copy link
Copy Markdown
Contributor

ruilvo commented Jul 26, 2021

For the record: closes #1779

@madebr
Copy link
Copy Markdown
Contributor

madebr commented Jul 26, 2021

Thanks for your first submission.
It looks very good, although it lacks support for Macos and MSVC.

samuel-emrys and others added 2 commits July 30, 2021 23:30
Co-authored-by: SpaceIm <30052553+SpaceIm@users.noreply.github.com>
Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>
* Fix CMake installation process
* Refactor CMakeLists to be operated from the root source directory
  rather than source_subfolder. This removes the requirements to use the
  shutil package from within conanfile.py
* Transition to usage of find_package for Threads library. This will
  allow thread library discovery to be performed in an OS agnostic way.
* Test consumer package sets the required MPCCS_DATA environment
  variable to the data folder within the conan package folder rather
  than copying it to the consumers working directory. This is for CCI
  CI runner testing efficiency purposes, elimintating the need for a
  copy.
@conan-center-bot

This comment has been minimized.

This will ideally make it easier for the user to understand the
requirements of them to correctly configure the MPCCS_DATA environment
variable prior to attempting to use the geotrans library.
@conan-center-bot

This comment has been minimized.

* Delete fPIC option when shared library is being built
* Remove superfluous shutil import
@conan-center-bot

This comment has been minimized.

samuel-emrys and others added 2 commits July 31, 2021 01:33
Co-authored-by: Rui Oliveira <ruimail24@gmail.com>
* Remove superfluous fPIC management from config_options function
* Remove superfluous C library requirements to remove cpp flags
@conan-center-bot

This comment has been minimized.

* Link MSPdtcc to MSPCoordinateConversionService to satisfy linkage
  requirements on macOS. This rectifies CI failures.
* Remove cmake_find_package(_multi) assignments from conanfile.py at the
  advice of @madebr
@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

* Move responsibility for setting MSPCCS_DATA environment variable from consumer to package
* Remove usage output from build method
* Remove explicit assignment of resdir value

Co-authored-by: SpaceIm <30052553+SpaceIm@users.noreply.github.com>
@conan-center-bot

This comment has been minimized.

* Remove version number of library from CMakeLists.txt
* Remove version number of library from conanfile.py
* Move definition of CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS from conanfile to
  CMakeLists.txt
* Add commentary on requisite environment variables to be set to
  consumer conanfile.py
* Re-add call to tools.environment_append to ensure that MPCCS_DATA
  environment variable is set when executing the example binary
@conan-center-bot

This comment has been minimized.

@jgsogo
Copy link
Copy Markdown
Contributor

jgsogo commented Sep 28, 2021

I've written to the organization to see if it is possible to get a link with versioned sources... let's see if they answer in a couple of days.

@samuel-emrys
Copy link
Copy Markdown
Contributor Author

I've written to the organization to see if it is possible to get a link with versioned sources... let's see if they answer in a couple of days.

To follow this up, we received a response from NGA today. My understanding of the response is that because they're not interested in supporting legacy versions, they are not going to provide a versioned download link at this stage. They have indicated that they will consider the wider community need for a versioned download link and may revise this position in the future.

My read of this is that they may be convinced to go to the effort of providing a download link if geotrans sees sufficient popularity on conan, if there are sufficient complaints about packages breaking when they release 3.9 (scheduled within the next 9 months), or perhaps just part of their 3.9 release process.

In the meantime, it appears as though finding an alternate way to mirror the source code would be the best way forward. @jgsogo do you agree with my summary/have anything to add?

@jgsogo
Copy link
Copy Markdown
Contributor

jgsogo commented Oct 14, 2021

Yes, same message.

I'm proposing a PR here to store these sources (conan-io/cci-sources-backup#2). We cannot use regular Git because the file is too big, and (free) LFS storage/bandwith in GitHub is quite limited. We can configure LFS to use Artifactory, so we have plenty of room for these files.

However, my main concern now is how to get the link from the repo. It requires some translation from

version https://git-lfs.github.com/spec/v1
oid sha256:baa72d3b1ae12f237a8ad30f2deb3fed2b80feb759528ea0a72b4b42cb77c565
size 159618792

to the actual URL:

https://c3i.jfrog.io/artifactory/cci-sources-backup/objects/ba/a7/baa72d3b1ae12f237a8ad30f2deb3fed2b80feb759528ea0a72b4b42cb77c565

Random thoughts:

  • given that we only need to get the URL once, probably that tranlations is not a problem at all
  • is the Git repo still useful to track the sources?
  • should we just use a generic Artifactory repo and forget about Git proxy?

Copy link
Copy Markdown
Contributor

@jgsogo jgsogo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, use sources from the mirror in our Artifactory.

@samuel-emrys
Copy link
Copy Markdown
Contributor Author

Yes, same message.

I'm proposing a PR here to store these sources (conan-io/cci-sources-backup#2). We cannot use regular Git because the file is too big, and (free) LFS storage/bandwith in GitHub is quite limited. We can configure LFS to use Artifactory, so we have plenty of room for these files.

However, my main concern now is how to get the link from the repo. It requires some translation from

version https://git-lfs.github.com/spec/v1
oid sha256:baa72d3b1ae12f237a8ad30f2deb3fed2b80feb759528ea0a72b4b42cb77c565
size 159618792

to the actual URL:

https://c3i.jfrog.io/artifactory/cci-sources-backup/objects/ba/a7/baa72d3b1ae12f237a8ad30f2deb3fed2b80feb759528ea0a72b4b42cb77c565

Random thoughts:

* given that we only need to get the URL once, probably that _tranlations_ is not a problem at all

* is the Git repo still useful to track the sources?

* should we just use a generic Artifactory repo and forget about Git proxy?

I realise that we're moving forward with a generic Artifactory repo in lieu of a LFS solution for the moment, but to provide some more discussion about why the Artifactory solution is preferred (at least from my perspective). There are practical considerations to using LFS that are messy. Namely, what is the desired workflow? Normally, this is:

  1. User forks repo
  2. User makes changes
  3. User submits PR

There seem like two alternatives here:

  1. Users are able to configure their forked repo to use JFrog Artifactory to back LFS. This would be required as users would be unable to push large file changes to their fork otherwise. This would mean they would be unable to make a PR as the changes can't be propagated to their github remote. I can't imagine this is ideal.
  2. Only users who can engage directly with the cci-sources-backup repo can make changes. This circumvents the need to submit a PR from a fork, but limits the number of people capable of making changes. How can the community at large contribute here? I guess the solution would be issues with instructions that require action from JFrog staff.

I guess the Artifactory solution here is really the same as solution (2) above, as I would imagine only JFrog staff will have the ability to upload new sources (?). Regardless, I think the Artifactory solution simplifies things a bit as solution (1) becomes infeasible. The URL is simpler too.

@madebr
Copy link
Copy Markdown
Contributor

madebr commented Oct 14, 2021

Let's KISS this. git is a handy tool, but we don't have to push it everywhere.

* Update geotrans 3.8 source URL to use JFrog Artifactory. This resolves a build reproducibility issue caused by the fact that NGA don't host a versioned mirror of the source files. The JFrog mirror provided is now versioned and will be able to be downloaded even after the release of geotrans 3.9

Co-authored-by: Javier G. Sogo <jgsogo@gmail.com>
@conan-center-bot
Copy link
Copy Markdown
Contributor

All green in build 15 (77a972e897d66b530c28e25f7c199c2f443c7f68):

  • geotrans/3.8@:
    All packages built successfully! (All logs)

Copy link
Copy Markdown
Contributor

@jgsogo jgsogo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Sorry for the delay and all the back and forth regarding the sources... but finally the package will be there. Thanks a lot for your patience!

@SSE4
Copy link
Copy Markdown
Contributor

SSE4 commented Oct 15, 2021

Let's KISS this. git is a handy tool, but we don't have to push it everywhere.

KISS is exactly the reason, that's why we have chosen plain artifactory over artifactory + git lfs

@conan-center-bot conan-center-bot merged commit bda1285 into conan-io:master Oct 15, 2021
@SSE4
Copy link
Copy Markdown
Contributor

SSE4 commented Oct 15, 2021

finally!
ельцин-ельцин

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

Successfully merging this pull request may close these issues.

[request] geotrans/3.8

8 participants