# Distinguishing projects from packages

**URL:** <https://discourse.julialang.org/t/distinguishing-projects-from-packages/153>\
**Category:** Internals & Design\
**Tags:** packages, code-organization, project\
**Created:** [November 7, 2016, 6:37am UTC](https://discourse.julialang.org/t/distinguishing-projects-from-packages/153 "2016-11-07T06:37:58Z")\
**Posts on this page:** 1\
**Showing post:** 40

<div class="post-metadata">

**Author:** ![tamasgal](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamasgal/32/27946_2.png) [@tamasgal](https://discourse.julialang.org/u/tamasgal)\
**Post date:** [January 7, 2017, 3:35pm UTC](https://discourse.julialang.org/t/distinguishing-projects-from-packages/153/40 "2017-01-07T15:35:18Z")

</div>

Similar to mauro, I also have tons of command line utilities in my Python packages. The users use them as libraries but have some terminal commands for common operations (they even provide them so I can add them in future releases).

I like how setuptools for Python manages this command line tools as “hooks”. You define in a configuration file the name of the command and the entry function to execute, like:

```julia
entry_points={
    'console_scripts': [
        'foo = foo.tools.cmd:foonction',
    ],
}

```

Many Python packages provide such tools and at least in our collaboration we use them on a daily basis…

---

_[View the full topic](https://discourse.julialang.org/t/distinguishing-projects-from-packages/153)._