Closed westurner closed 4 years ago
I'm not a Navigator user, but I can't think of any overlap between it and anaconda-project. The repo address https://github.com/ContinuumIO/navigator is correct; it just won't work for the public because it's a private Anaconda repository.
So, if there was e.g. a make
task that launches a GUI, you would just add that command tuple to both?:
meta.yml
(if you're decided that it's easy and appropriate to just package your project as one or more conda packages)anaconda-project.yml
The conda-package tutorial you link to should cover what you need to do to add an icon for a new GUI app to Navigator, letting it be installed and launched from there. Conda is the right way to distribute tools that you want other people to build on.
anaconda-project is meant for different things; it captures runnable projects (a final endpoint), typically invoking some commands rather than actually providing a Python library or Python-based program. It's true that you can use anaconda-project to capture anything runnable, including the source code for a runnable application, but it's not really meant for that.
In any case, I don't think there's any direct path from an anaconda-project into Navigator; you'd still then have to package it as a conda package if you want it to show up in Navigator.
Not sure if that is what you're asking for here?
Maybe I'm not understanding the difference between a project and package (that can produce additional packages or just define a set of named build tasks with dependency edges and topological sort)?
https://github.com/Anaconda-Platform/anaconda-project/blob/master/README.md#put-another-way
What is the difference between a software build task and tasks / named build steps (edit: with additional graph roots beyond the current build
task)?
Could there be a conda tasks
or a conda run
command that can run the commands specified in this additional .yml file?
Could the tasks defined in anaconda-project.yml be merged into meta.yml?
The link above puts it clearly, I think:
Traditional build scripts such as setup.py automate "building" the project
(going from source code to something runnable), while anaconda-project
automates "running" the project (taking build artifacts and doing any
necessary setup prior to executing them).
Pretty much every configurable utility is Turing complete and can thus be used to do anything with enough forcing, but here a Conda package is meant for things that you share as tools (a starting point), and an anaconda-project is meant for completed projects you share for their own sake (an ending point).
Navigator only supports conda packages as far as I know, but it could add a separate category for projects; that would be up to Navigator, not anaconda-project.
I'm not sure what adding anaconda-project-style commands to meta.yml would achieve; seems like a category error. A conda package is just installed or not installed, and then you provide options to it; I can't see a role for it capturing various commands and executing those other than whatever is inside the package already does.
You can (and should) distribute things that depend upon conda packages as conda packages.
Packages are for reproducible published works.
When I run npm run mycmd
it finds the command listed under the scripts: {"mycmd": "echo build"}
key of the package.json. Simple, duplicates GNU Make in a platform-independent way, and I can learn how to build and run the package/project from reading the package.json.
https://docs.npmjs.com/cli/run-script
Is that possible with conda already, or would there need to be functionality in conda that supports a different configuration syntax than anaconda-project.yml in meta.yml?
I don't know how many times I've - despite there being a perfectly good packaging ecosystem for the given distro - instead chosen to create a tarball by hand with a shell script or a makefile and then later realized that I should've done as much with the packaging system as possible so that I don't need additional conventions or tools that reinvent the wheel yet again to just build the thing and run the tests some time later.
It may be helpful to link to the docs for conda skeleton
and/or conda-smithy. Conda-smithy is very prescriptive about CI platforms (for Linux, Mac, and Windows from the start) which may not be what you want for a given project; but, TBH, if you're creating a project/package without a CI config and at least one test, you're probably doing it wrong.
(These cookiecutters for [reproducible] data science could support conda and e.g. nbdev https://github.com/cookiecutter/cookiecutter/blob/f83c880c63cae3db478b6291dff54a3d93145ae1/README.md#data-science )
I think this is definitely an interesting discussion but it genuinely is not in the right place. This is the issue tracker for a very specific Python package to manage projects. If a specific, well-defined improvement to anaconda-project can be articulated here I'm all ears, but I don't think it's the best place for larger discussions.
TIL you can add entries to a conda package's meta.yml with icons and a summary and stuff: https://docs.continuum.io/anaconda/navigator/tutorials/nav-app/
Is there functional overlap between anaconda-project and anaconda navigator worth at least documenting?
(I'm not sure where the navigator repo is now? https://anaconda.org/anaconda/anaconda-navigator links to https://github.com/ContinuumIO/navigator which apparently doesn't exist anymore?)