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

[question] export-pkg use of attributes in_local_cache and develop #2513

Closed
3 tasks done
drmacdon opened this issue Feb 23, 2018 · 6 comments
Closed
3 tasks done

[question] export-pkg use of attributes in_local_cache and develop #2513

drmacdon opened this issue Feb 23, 2018 · 6 comments
Assignees
Milestone

Comments

@drmacdon
Copy link

With conan 1.0.4, when invoking,

conan export-pkg -bf build -if build -sf . -f . owner/channel

The attributes are in_local_cache=True and develop=False but I don't think they should be since at the point that it is invoked we are exporting to the local_cache.

It is problematic because I don't know where my sources are when packaging because they are really based upon how it is being built either via install (with source()) or a manual build declaring source locations followed by the export-pkg. While the build operation knows from either attribute, export-pkg offers no such clues.

It stems from the fact that my source() clones from git necessarily into a sub-folder to ensure it is empty. While manually building/export-pkg it is truly the source_folder. Thus the package() operation may or may not be in a sub-folder.

I can always copy from both locations with no real impact, just feels that export-pkg is inconsistent with respect to those variables.

Thanks!

  • I've read the CONTRIBUTING guide.
  • I've specified the Conan version, operating system version and any tool that can be relevant.
  • I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.
@lasote
Copy link
Contributor

lasote commented Feb 23, 2018

About the in_local_cache=True and develop=False, I confirmed that, and it is weird, I agree. I'm labeling the issue as "bug".
But I still don't know how it is related with the sources location.

The package method will be called twice, one with the specified source folder as the current folder, and another one with the specified build folder. (if they are the same it won't be called twice). So you have to pass the correct source folder to the command, just the same as the conan build or conan package commands. If your sources are in a subfolder and you want to consider the source_folder the folder with the cloned repository, it is ok, but in your recipe, to be able to operate correctly in the local flow or in a create, you have to append the folder of the cloned sources. e.j:

 with tools.chdir(os.path.join(self.source_folder, "mysubfolder")):
        env_build = AutoToolsBuildEnvironment(self)

@lasote
Copy link
Contributor

lasote commented Feb 23, 2018

Update: The in_local_cache=True have kind of sense, because conan exports the recipe and then the package, so the recipe is actually living in the cache at that point.
Maybe develop should be True but please, I need to understand how all is related to your sources problem to know what is the fix required.

@memsharded
Copy link
Member

The develop variable is mostly used within the build() method to decide to run some tests on the code, or something related to the build. I haven't seen it applied yet to the package() command, but I understand it could be a good way to differentiate the package() code when running from export-pkg and when running from conan create, packaging from the build folder in the cache. So I am good with changing it to True, it can be considered a bug.

@drmacdon
Copy link
Author

How does it relate to sources location? Indirectly.

Stems from in-source builds where I have the conanfile.py inside my source repository and wishing to sometimes build via source() against a versioned tag and other times from my local sources without a tag. (Issue##2291)

When the source() method is invoked, it does so after the exports have been copied to the source folder. Not entirely certain why exports needs to come before source() but it does and ensures that the self.source_folder is not an empty folder if an exports attribute is provided.

In the source() when cloning from a git repository, git will except a folder of "." to clone into provided it is an empty folder. Because of the exports, we need to clone into a sub-folder to ensure we have an empty folder. So, in my scenario building from a git tag ends up in a sub-folder under self.source_folder. The package() method is thus relative to the sub-folder for locating includes.

For all the commands which take a source folder as an option, the ideal scenario is to just pass the actual source folder. But since source() didn't get called I end up in a scenario within package() that sometimes my source is in a sub-folder while other times it is the self.source_folder with no way to nicely tell.

Some approaches:

  1. A bad approach would be when invoking the commands to tell it that my source folder is in the parent folder of where it physically is locally located but that assumes I've named it the same as what my sub-folder source would.

  2. A nicer approach (my ideal) would be to actually clone the git repository to "." so the rest of the operations can just see it as self.source_folder with no decision on the way in which it was invoked.

  3. What I presently do is using a sub-folder which is not already being used within the repository (or build) so its existence would imply a clone from git, otherwise it is an in-source build.

  4. package() my files from both my possible locations (in addition to being called with both source & build source_folders as pointed out by lasote above).

  5. package() with more wild cards so it doesn't matter

  6. The solution I was presently going for was conditional logic to leverage either in_local_cache or develop. But the checks are a slight pain.

@memsharded
Copy link
Member

So most likely, yes, I think the develop value can be changed for this use case, it is a bug. So it will help with your approach 6)

Overall, I think there are possible improvements that can be done for #2291, that will alleviate some of the things reported here. We have been discussing possibilities, we will be talking in that #2291 issue.

@memsharded memsharded self-assigned this Feb 23, 2018
@memsharded memsharded added this to the 1.1 milestone Feb 23, 2018
@ghost ghost added the stage: review label Feb 23, 2018
@ghost ghost removed the stage: review label Feb 23, 2018
@memsharded
Copy link
Member

Done, the fix will be released in 1.1 (develop=True) for export-pkg.

The rest of the issues can be followed in #2291, but please comment or re-open this issue or a new one if you think it is necessary. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants