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

add datreant recipes. #1144

Merged
merged 11 commits into from
Sep 2, 2016
Merged

add datreant recipes. #1144

merged 11 commits into from
Sep 2, 2016

Conversation

kain88-de
Copy link
Contributor

This includes two recipes for datreant. One is the empty namespace
package 'datreant' and the other contains the actual core pacakge
for datreant. The config for datreant itself is to allow to install
a simple namespace package. For 'datreant.core' the extra build scripts
are needed to remove the '*-nspkg.pth' file produced by setuptools,
this is to have anaconda-verify pass with the package.

I know this deviates from the usual structure that you prefer for normal packages. But the namespace package means it has to be treated differently.

Another question I have. This introduces two packages with one (datreant) basically being empty.
I currently decided to pack both into one PR to give some context. But I can split them up if that is preferred.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/datreant, recipes/datreant.core) and found some lint.

Here's what I've got...

For recipes/datreant:

  • The home item is expected in the about section.
  • The recipe could do with some maintainers listed in the "extra/recipe-maintainers" section.
  • The recipe must have a build/number section.

For recipes/datreant.core:

  • The recipe could do with some maintainers listed in the "extra/recipe-maintainers" section.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/datreant, recipes/datreant.core) and found some lint.

Here's what I've got...

For recipes/datreant:

  • The home item is expected in the about section.
  • The recipe must have a build/number section.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/datreant, recipes/datreant.core) and found it was in an excellent condition.

@kain88-de
Copy link
Contributor Author

ping @datreant/coredevs, @dotsdl as well.

@dotsdl
Copy link
Member

dotsdl commented Jul 24, 2016

Awesome! I'm really curious if this works on Windows as written (AppVeyor). Thanks @kain88-de! This is a big deal.

@kain88-de
Copy link
Contributor Author

I'm not sure why the datreant package can't be build it works locally with conda build .

@dotsdl
Copy link
Member

dotsdl commented Jul 24, 2016

I'm having a look at all the CI results now. Not sure what to do with CircleCI. the Linux Travis build worked, but not OSX. Also Windows (AppVeyor) failed.

Do you have a Mac? I don't have a Windows machine lying around; not sure what people do to troubleshoot Windows builds.


source:
git_url: https://github.com/datreant/datreant.core.git
git_tag: release-{{ version }}
Copy link
Member

Choose a reason for hiding this comment

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

We prefer to use tarballs. Could we please switch this over to one?

@dotsdl
Copy link
Member

dotsdl commented Jul 24, 2016

So it's the namespace package that isn't building. On both OSX and Windows we get something like:

no source - creating empty work folder
Traceback (most recent call last):
  File "/Users/travis/miniconda/bin/conda-build-all", line 9, in <module>
    load_entry_point('conda-build-all==0.13.1', 'console_scripts', 'conda-build-all')()
  File "/Users/travis/miniconda/lib/python3.5/site-packages/conda_build_all/cli.py", line 85, in main
    b.main()
  File "/Users/travis/miniconda/lib/python3.5/site-packages/conda_build_all/builder.py", line 230, in main
    built_dist_location = self.build(meta)
  File "/Users/travis/miniconda/lib/python3.5/site-packages/conda_build_all/builder.py", line 187, in build
    return bldpkg_path(build.build(meta.meta))
  File "/Users/travis/miniconda/lib/python3.5/site-packages/conda_build_all/build.py", line 32, in build
    build_module.build(meta, post=None, need_source_download=True, **kwd)
  File "/Users/travis/miniconda/lib/python3.5/site-packages/conda_build/build.py", line 548, in build
    os.makedirs(source.WORK_DIR)
  File "/Users/travis/miniconda/lib/python3.5/os.py", line 241, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: '/Users/travis/miniconda/conda-bld/work'

See AppVeyor and Travis results for details.

@jakirkham
Copy link
Member

Yep, this appears to be a conda-build-all bug. Though there may be some interaction with conda-build that is causing problems. See this issue ( conda-tools/conda-build-all#51 ).

@dotsdl
Copy link
Member

dotsdl commented Jul 25, 2016

Thanks @jakirkham for bringing this to the attention of the upstream tools. Is there anything we can do as a workaround, or would you suggest waiting for now?

@jakirkham
Copy link
Member

Let's wait and see what upstream says. Normally the developer is very responsive and he's an admin at conda-forge.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/datreant, recipes/datreant.core) and found some lint.

Here's what I've got...

For recipes/datreant.core:

  • Failed to even lint the recipe (might be a conda-smithy bug) 😢

@kain88-de
Copy link
Contributor Author

I've created a commit to restart the travis build as this should be fixed with the latest conda-build-all.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/datreant, recipes/datreant.core) and found it was in an excellent condition.

@kain88-de
Copy link
Contributor Author

This currently fails because the python-pathlib2 package is not available on all platforms. I'll check with that package now.

@kain88-de
Copy link
Contributor Author

This package currently doesn't work on windows. We would need to make some major changes to make it work under windows. Will that be a problem?

@ericdill
Copy link
Member

This package currently doesn't work on windows. We would need to make some major changes to make it work under windows. Will that be a problem?

There are a number of packages on conda-forge that do not currently build on windows (here's a rough list), so that's fine. Just add:

  skip: True  # [win]

to the build section


extra:
recipe-maintainers:
- datreant/coredevs
Copy link
Member

Choose a reason for hiding this comment

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

Ah, so, I don't think this would work. Though I'm actually a little unsure. It is better to list explicitly when members are maintainers by their handles.

@kain88-de
Copy link
Contributor Author

Fixed all comments. Seriously thanks for all the help.

@kain88-de
Copy link
Contributor Author

There is something odd. The logs on circleci show an error

INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/main.py", line 90, in wrap_session
INTERNALERROR>     config._do_configure()
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/config.py", line 839, in _do_configure
INTERNALERROR>     self.hook.pytest_configure.call_historic(kwargs=dict(config=self))
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 729, in call_historic
INTERNALERROR>     self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 338, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 333, in <lambda>
INTERNALERROR>     _MultiCall(methods, kwargs, hook.spec_opts).execute()
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 596, in execute
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/assertion/__init__.py", line 68, in pytest_configure
INTERNALERROR>     hook = rewrite.AssertionRewritingHook()  # noqa
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/assertion/rewrite.py", line 50, in __init__
INTERNALERROR>     self._register_with_pkg_resources()
INTERNALERROR>   File "/opt/conda/envs/_test/lib/python3.5/site-packages/_pytest/assertion/rewrite.py", line 204, in _register_with_pkg_resources
INTERNALERROR>     pkg_resources.register_loader_type(cls, pkg_resources.DefaultProvider)
INTERNALERROR> AttributeError: module 'pkg_resources' has no attribute 'register_loader_type'

Still it is reported everything has passed. This likely isn't important for this package since the failure occurs when I run the unit-test packages with datreant.core. Still I find it strange that an error is raised an the build succeds

@kain88-de
Copy link
Contributor Author

The builds are passing now. Anything else that needs to be done?


build:
number: 1
skip: True # [win]
Copy link
Contributor

Choose a reason for hiding this comment

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

We are skipping windows but have a bld.bat?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sorry forget to remove that when I deactivated the windows build.

This includes two recipes for datreant. One is the empty namespace
package 'datreant' and the other contains the actual core pacakge
for datreant. The config for datreant itself is to allow to install
a simple namespace package. For 'datreant.core' the extra build scripts
are needed to remove the '*-nspkg.pth' file produced by setuptools,
this is to have anaconda-verify pass with the package.
weird that here the package name is different from the repository name.
remove anchor and deactivate build for windows
@kain88-de
Copy link
Contributor Author

all checks pass now again after a rebase against master.


about:
home: http://datreant.org/
license: BSD 3-Clause
Copy link
Member

Choose a reason for hiding this comment

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

Please ask upstream to include the license file in MANIFEST.in. Also please note the issue/PR here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why should the license file be included in the MANIFEST.in? I haven't worked with that file yet. We note the license in the setup.py.

Also this change in the license will only be released in the next version.

Copy link
Member

Choose a reason for hiding this comment

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

It ensures that the license file shows up in sdists and other packages generated from the source. This is important as it is required by the BSD license. Further it will make it easy for this package to comply with the license as we can do something like license_file: LICENSE to include it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK I understand. I'll add the files. This won't be released until version 0.8 though which is still some at some unknown time in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Created Issue datreant/datreant#94

Copy link
Member

Choose a reason for hiding this comment

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

Of course. We are just trying to improve compliance on this front.

@patricksnape
Copy link
Contributor

@jakirkham I think this looks all good to me as long as we are happy with the namespace story? I'm not aware of our hosting of any other namespace packages so I'm reluctant to pull this in myself without one last second pair of eyes.

@jakirkham
Copy link
Member

Agreed. I think I'm also happy with this.

The namespace recommendation seems to come from @ilanschnell. Given they are doing this with the backports packages and it is a pretty simple way to do it, I'm ok with it. Maybe @msarahan can give it a quick look and send it in if he is happy (passes the buck 💵 😄).

@kain88-de
Copy link
Contributor Author

Ping

@msarahan
Copy link
Member

msarahan commented Sep 2, 2016

I have no experience with namespace packages, but have discussed this with @ilanschnell. It's worth a try here.

@msarahan msarahan merged commit 64a66cd into conda-forge:master Sep 2, 2016
@dotsdl
Copy link
Member

dotsdl commented Sep 2, 2016

Thanks @msarahan!

@kain88-de
Copy link
Contributor Author

Thanks

@kain88-de kain88-de deleted the datreant branch September 3, 2016 06:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

7 participants