Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #102603 > unrolled thread

Python's import situation has driven me to the brink of imsanity

Back to article view | Back to comp.lang.python

Contents

  Python's import situation has driven me to the brink of imsanity dimva13@gmail.com - 2016-02-06 18:47 -0800
    Re: Python's import situation has driven me to the brink of imsanity Chris Angelico <rosuav@gmail.com> - 2016-02-07 13:52 +1100
    Re: Python's import situation has driven me to the brink of imsanity Kevin Conway <kevinjacobconway@gmail.com> - 2016-02-07 06:34 +0000
      Re: Python's import situation has driven me to the brink of imsanity dimva13@gmail.com - 2016-02-07 06:13 -0800
        Re: Python's import situation has driven me to the brink of imsanity Kevin Conway <kevinjacobconway@gmail.com> - 2016-02-07 16:09 +0000
          Re: Python's import situation has driven me to the brink of imsanity dimva13@gmail.com - 2016-02-07 16:38 -0800
            Re: Python's import situation has driven me to the brink of imsanity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-02-10 00:31 +0000
            Re: Python's import situation has driven me to the brink of imsanity Sivan Greenberg <sivan@vitakka.co> - 2016-02-10 21:05 +0200
            Re: Python's import situation has driven me to the brink of imsanity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-10 21:16 +0000
        Re: Python's import situation has driven me to the brink of imsanity Sivan Greenberg <sivan@vitakka.co> - 2016-02-07 18:15 +0200
    Re: Python's import situation has driven me to the brink of imsanity Sivan Greenberg <sivan@vitakka.co> - 2016-02-07 13:43 +0200

#102603 — Python's import situation has driven me to the brink of imsanity

No, that's not a typo, it's the name of a package I created. :)

The problems I have with python's import system are detailed in the README of my package here: https://github.com/vadimg/imsanity

Basically, relative imports are broken if you like running scripts as executables, so the only real solution is modifying PYTHONPATH every time you switch projects, which is also not ideal.

Some people suggest adding various boilerplate to the beginning of every file to fix this, ranging from the crazy stuff in PEP 0366 to the slightly more sane sys.path.append(os.path.realpath(os.path.join(os.path.dirname(__file__), path_to_root))), where path_to_root is some number of '../'s depending on the file's location. Neither can be used indiscriminately as a macro, which is annoying.

Imsanity allows you to make imports usable (not ideal, but at least usable) for python projects without having to manage PYTHONPATHs or do whacky stuff like running files with python -m or put even whackier boilerplate at the top of every file. And all it requires is 'import imsanity' at the top of every file. You can put it in a macro or even just type it because it's short and easy to remember.

My question is: is this crazy? Please tell me there's a better way and I just wasted my time creating this package. There's nothing I'd like to hear more.

[toc] | [next] | [standalone]

#102604

On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> Imsanity allows you to make imports usable (not ideal, but at least usable) for python projects without having to manage PYTHONPATHs or do whacky stuff like running files with python -m or put even whackier boilerplate at the top of every file. And all it requires is 'import imsanity' at the top of every file. You can put it in a macro or even just type it because it's short and easy to remember.
>
> My question is: is this crazy? Please tell me there's a better way and I just wasted my time creating this package. There's nothing I'd like to hear more.

Well, anything that makes you type "import imsanity" at the top of
every script MUST be crazy. :) I don't know about the actual
content/purpose though. Good luck with it!

ChrisA

[toc] | [prev] | [next] | [standalone]

#102610

> My question is: is this crazy? Please tell me there's a better way and I
just wasted my time creating this package.

There is a better way and you have wasted your time creating this package.

I hear your problem statement as asking two questions. The first is: What
is the right way to include executable content in my Python project? The
second is: How do I expose executable content from a Python project?

As to the first question, from your project README:
> Say you have a python project (not a package), with the following
structure:

All Python code that you want to install and make available in any form,
import or executable, _must_ be contained within a Python package.
Organizing Python code in any way other than Python packages will result in
the challenges you have described. The correct way to include executable
content is to place the Python code within the package structure. It should
not be put in other directories within the repository root.

As to the second question, once all Python code is contained within a
package that can be installed you can use setuptools entry points to expose
the executable code. The setup() function from setuptools that is used to
create setup.py files has an argument called 'entry_points' that allows you
to expose executable content over the command line. See [1] and [2] for
more details.

Feel free to reach out to me off-list if you have a specific project you
need advice on. The rules for organizing and packaging Python code aren't
complex but they tend to cause new Python developers to stumble at first. A
general rule I give everyone when talking about packaging or importing
code: If you have to modify sys.path to makes something work then you have
most certainly made a mistake.

[1]
https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
[2]
http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point


On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > Imsanity allows you to make imports usable (not ideal, but at least
> usable) for python projects without having to manage PYTHONPATHs or do
> whacky stuff like running files with python -m or put even whackier
> boilerplate at the top of every file. And all it requires is 'import
> imsanity' at the top of every file. You can put it in a macro or even just
> type it because it's short and easy to remember.
> >
> > My question is: is this crazy? Please tell me there's a better way and I
> just wasted my time creating this package. There's nothing I'd like to hear
> more.
>
> Well, anything that makes you type "import imsanity" at the top of
> every script MUST be crazy. :) I don't know about the actual
> content/purpose though. Good luck with it!
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#102630

I see that this would work once you've installed the package, but how do you develop it? Say you are working on a change that modifies both email.py and reports.py. Do you run setup.py every time you make a change in email.py?

On Sunday, February 7, 2016 at 1:35:15 AM UTC-5, Kevin Conway wrote:
> > My question is: is this crazy? Please tell me there's a better way and I
> just wasted my time creating this package.
> 
> There is a better way and you have wasted your time creating this package.
> 
> I hear your problem statement as asking two questions. The first is: What
> is the right way to include executable content in my Python project? The
> second is: How do I expose executable content from a Python project?
> 
> As to the first question, from your project README:
> > Say you have a python project (not a package), with the following
> structure:
> 
> All Python code that you want to install and make available in any form,
> import or executable, _must_ be contained within a Python package.
> Organizing Python code in any way other than Python packages will result in
> the challenges you have described. The correct way to include executable
> content is to place the Python code within the package structure. It should
> not be put in other directories within the repository root.
> 
> As to the second question, once all Python code is contained within a
> package that can be installed you can use setuptools entry points to expose
> the executable code. The setup() function from setuptools that is used to
> create setup.py files has an argument called 'entry_points' that allows you
> to expose executable content over the command line. See [1] and [2] for
> more details.
> 
> Feel free to reach out to me off-list if you have a specific project you
> need advice on. The rules for organizing and packaging Python code aren't
> complex but they tend to cause new Python developers to stumble at first. A
> general rule I give everyone when talking about packaging or importing
> code: If you have to modify sys.path to makes something work then you have
> most certainly made a mistake.
> 
> [1]
> https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
> [2]
> http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point
> 
> 
> On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com> wrote:
> 
> > On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > > Imsanity allows you to make imports usable (not ideal, but at least
> > usable) for python projects without having to manage PYTHONPATHs or do
> > whacky stuff like running files with python -m or put even whackier
> > boilerplate at the top of every file. And all it requires is 'import
> > imsanity' at the top of every file. You can put it in a macro or even just
> > type it because it's short and easy to remember.
> > >
> > > My question is: is this crazy? Please tell me there's a better way and I
> > just wasted my time creating this package. There's nothing I'd like to hear
> > more.
> >
> > Well, anything that makes you type "import imsanity" at the top of
> > every script MUST be crazy. :) I don't know about the actual
> > content/purpose though. Good luck with it!
> >
> > ChrisA
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

[toc] | [prev] | [next] | [standalone]

#102632

You can use 'setup.py develop' or 'pip install -e' to install your package
in editable mode. It makes it so your local code is used. Modifications are
seen immediately.

On Sun, Feb 7, 2016, 08:16  <dimva13@gmail.com> wrote:

> I see that this would work once you've installed the package, but how do
> you develop it? Say you are working on a change that modifies both email.py
> and reports.py. Do you run setup.py every time you make a change in
> email.py?
>
> On Sunday, February 7, 2016 at 1:35:15 AM UTC-5, Kevin Conway wrote:
> > > My question is: is this crazy? Please tell me there's a better way and
> I
> > just wasted my time creating this package.
> >
> > There is a better way and you have wasted your time creating this
> package.
> >
> > I hear your problem statement as asking two questions. The first is: What
> > is the right way to include executable content in my Python project? The
> > second is: How do I expose executable content from a Python project?
> >
> > As to the first question, from your project README:
> > > Say you have a python project (not a package), with the following
> > structure:
> >
> > All Python code that you want to install and make available in any form,
> > import or executable, _must_ be contained within a Python package.
> > Organizing Python code in any way other than Python packages will result
> in
> > the challenges you have described. The correct way to include executable
> > content is to place the Python code within the package structure. It
> should
> > not be put in other directories within the repository root.
> >
> > As to the second question, once all Python code is contained within a
> > package that can be installed you can use setuptools entry points to
> expose
> > the executable code. The setup() function from setuptools that is used to
> > create setup.py files has an argument called 'entry_points' that allows
> you
> > to expose executable content over the command line. See [1] and [2] for
> > more details.
> >
> > Feel free to reach out to me off-list if you have a specific project you
> > need advice on. The rules for organizing and packaging Python code aren't
> > complex but they tend to cause new Python developers to stumble at
> first. A
> > general rule I give everyone when talking about packaging or importing
> > code: If you have to modify sys.path to makes something work then you
> have
> > most certainly made a mistake.
> >
> > [1]
> >
> https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
> > [2]
> >
> http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point
> >
> >
> > On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com> wrote:
> >
> > > On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > > > Imsanity allows you to make imports usable (not ideal, but at least
> > > usable) for python projects without having to manage PYTHONPATHs or do
> > > whacky stuff like running files with python -m or put even whackier
> > > boilerplate at the top of every file. And all it requires is 'import
> > > imsanity' at the top of every file. You can put it in a macro or even
> just
> > > type it because it's short and easy to remember.
> > > >
> > > > My question is: is this crazy? Please tell me there's a better way
> and I
> > > just wasted my time creating this package. There's nothing I'd like to
> hear
> > > more.
> > >
> > > Well, anything that makes you type "import imsanity" at the top of
> > > every script MUST be crazy. :) I don't know about the actual
> > > content/purpose though. Good luck with it!
> > >
> > > ChrisA
> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
> > >
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#102641

Running python setup.py develop doesn't work, it gives me this error: error: invalid command 'develop'

Running pip install -e . does work. This is somewhat reasonable, and I think may work for my purposes, but it has the following drawbacks:
- you have to create a fake package with a fake version, and all the setup.py boilerplate
- to get to your python files, you have to go through an additional subdirectory (ex: project_name/project_name/package.py)
- you have to remember to run pip install -e . before you can use anything inside the project
- you should be using a virtualenv (I am), otherwise things can get messy if you have these fake projects installed in a global location

All in all, this seems like a hack - I'm creating a fake package with a fake version just so I can do imports sanely. Still less of a hack than imsanity, though.

Thanks for the advice! I just wish it was better documented and easier to find. I have several years of professional python experience at 3 different companies, and I've never seen this solution anywhere - all the companies solved it by setting PYTHONPATH to the base directory. I'll try to spread the word.

On Sunday, February 7, 2016 at 11:09:35 AM UTC-5, Kevin Conway wrote:
> You can use 'setup.py develop' or 'pip install -e' to install your package
> in editable mode. It makes it so your local code is used. Modifications are
> seen immediately.
> 
> On Sun, Feb 7, 2016, 08:16  <dimva13@gmail.com> wrote:
> 
> > I see that this would work once you've installed the package, but how do
> > you develop it? Say you are working on a change that modifies both email.py
> > and reports.py. Do you run setup.py every time you make a change in
> > email.py?
> >
> > On Sunday, February 7, 2016 at 1:35:15 AM UTC-5, Kevin Conway wrote:
> > > > My question is: is this crazy? Please tell me there's a better way and
> > I
> > > just wasted my time creating this package.
> > >
> > > There is a better way and you have wasted your time creating this
> > package.
> > >
> > > I hear your problem statement as asking two questions. The first is: What
> > > is the right way to include executable content in my Python project? The
> > > second is: How do I expose executable content from a Python project?
> > >
> > > As to the first question, from your project README:
> > > > Say you have a python project (not a package), with the following
> > > structure:
> > >
> > > All Python code that you want to install and make available in any form,
> > > import or executable, _must_ be contained within a Python package.
> > > Organizing Python code in any way other than Python packages will result
> > in
> > > the challenges you have described. The correct way to include executable
> > > content is to place the Python code within the package structure. It
> > should
> > > not be put in other directories within the repository root.
> > >
> > > As to the second question, once all Python code is contained within a
> > > package that can be installed you can use setuptools entry points to
> > expose
> > > the executable code. The setup() function from setuptools that is used to
> > > create setup.py files has an argument called 'entry_points' that allows
> > you
> > > to expose executable content over the command line. See [1] and [2] for
> > > more details.
> > >
> > > Feel free to reach out to me off-list if you have a specific project you
> > > need advice on. The rules for organizing and packaging Python code aren't
> > > complex but they tend to cause new Python developers to stumble at
> > first. A
> > > general rule I give everyone when talking about packaging or importing
> > > code: If you have to modify sys.path to makes something work then you
> > have
> > > most certainly made a mistake.
> > >
> > > [1]
> > >
> > https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
> > > [2]
> > >
> > http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point
> > >
> > >
> > > On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com> wrote:
> > >
> > > > On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > > > > Imsanity allows you to make imports usable (not ideal, but at least
> > > > usable) for python projects without having to manage PYTHONPATHs or do
> > > > whacky stuff like running files with python -m or put even whackier
> > > > boilerplate at the top of every file. And all it requires is 'import
> > > > imsanity' at the top of every file. You can put it in a macro or even
> > just
> > > > type it because it's short and easy to remember.
> > > > >
> > > > > My question is: is this crazy? Please tell me there's a better way
> > and I
> > > > just wasted my time creating this package. There's nothing I'd like to
> > hear
> > > > more.
> > > >
> > > > Well, anything that makes you type "import imsanity" at the top of
> > > > every script MUST be crazy. :) I don't know about the actual
> > > > content/purpose though. Good luck with it!
> > > >
> > > > ChrisA
> > > > --
> > > > https://mail.python.org/mailman/listinfo/python-list
> > > >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

[toc] | [prev] | [next] | [standalone]

#102739

On 8 February 2016 at 00:38,  <dimva13@gmail.com> wrote:
> Running python setup.py develop doesn't work, it gives me this error: error: invalid command 'develop'

This is presumably because your setup.py script uses distutils rather
than setuptools: distutils doesn't have the develop command.

> Running pip install -e . does work.

That's because pip "injects setuptools" so that when you import
distutils in your setup.py your actually importing a monkey-patched
setuptools. You may as well import setuptools in your setup.py but
either way the recommended invocation is "pip install -e .".

--
Oscar

[toc] | [prev] | [next] | [standalone]

#102769

not entirely on-topic here, but is distutils still being in active use "in
the wild" ?

-Sivan

On Wed, Feb 10, 2016 at 2:31 AM, Oscar Benjamin <oscar.j.benjamin@gmail.com>
wrote:

> On 8 February 2016 at 00:38,  <dimva13@gmail.com> wrote:
> > Running python setup.py develop doesn't work, it gives me this error:
> error: invalid command 'develop'
>
> This is presumably because your setup.py script uses distutils rather
> than setuptools: distutils doesn't have the develop command.
>
> > Running pip install -e . does work.
>
> That's because pip "injects setuptools" so that when you import
> distutils in your setup.py your actually importing a monkey-patched
> setuptools. You may as well import setuptools in your setup.py but
> either way the recommended invocation is "pip install -e .".
>
> --
> Oscar
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Sivan Greenberg
Co founder & CTO
Vitakka Consulting

[toc] | [prev] | [next] | [standalone]

#102771

On 10/02/2016 19:05, Sivan Greenberg wrote:
> not entirely on-topic here, but is distutils still being in active use "in
> the wild" ?
>
> -Sivan
>

Given that there was distutils2 which took the same course as the 
Norwegian Blue, I would say no, distutils is not active.  I'll happily 
stand corrected.

As a slight aside, please don't top post, it's irritating, thanks :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#102633

I if it's more than few files, I use 'develop' as Kevin noted in the note
before:
- http://www.ewencp.org/blog/a-brief-introduction-to-packaging-python/

Hope this helps..

-Sivan

On Sun, Feb 7, 2016 at 6:09 PM, Kevin Conway <kevinjacobconway@gmail.com>
wrote:

> You can use 'setup.py develop' or 'pip install -e' to install your package
> in editable mode. It makes it so your local code is used. Modifications are
> seen immediately.
>
> On Sun, Feb 7, 2016, 08:16  <dimva13@gmail.com> wrote:
>
> > I see that this would work once you've installed the package, but how do
> > you develop it? Say you are working on a change that modifies both
> email.py
> > and reports.py. Do you run setup.py every time you make a change in
> > email.py?
> >
> > On Sunday, February 7, 2016 at 1:35:15 AM UTC-5, Kevin Conway wrote:
> > > > My question is: is this crazy? Please tell me there's a better way
> and
> > I
> > > just wasted my time creating this package.
> > >
> > > There is a better way and you have wasted your time creating this
> > package.
> > >
> > > I hear your problem statement as asking two questions. The first is:
> What
> > > is the right way to include executable content in my Python project?
> The
> > > second is: How do I expose executable content from a Python project?
> > >
> > > As to the first question, from your project README:
> > > > Say you have a python project (not a package), with the following
> > > structure:
> > >
> > > All Python code that you want to install and make available in any
> form,
> > > import or executable, _must_ be contained within a Python package.
> > > Organizing Python code in any way other than Python packages will
> result
> > in
> > > the challenges you have described. The correct way to include
> executable
> > > content is to place the Python code within the package structure. It
> > should
> > > not be put in other directories within the repository root.
> > >
> > > As to the second question, once all Python code is contained within a
> > > package that can be installed you can use setuptools entry points to
> > expose
> > > the executable code. The setup() function from setuptools that is used
> to
> > > create setup.py files has an argument called 'entry_points' that allows
> > you
> > > to expose executable content over the command line. See [1] and [2] for
> > > more details.
> > >
> > > Feel free to reach out to me off-list if you have a specific project
> you
> > > need advice on. The rules for organizing and packaging Python code
> aren't
> > > complex but they tend to cause new Python developers to stumble at
> > first. A
> > > general rule I give everyone when talking about packaging or importing
> > > code: If you have to modify sys.path to makes something work then you
> > have
> > > most certainly made a mistake.
> > >
> > > [1]
> > >
> >
> https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
> > > [2]
> > >
> >
> http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point
> > >
> > >
> > > On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com>
> wrote:
> > >
> > > > On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > > > > Imsanity allows you to make imports usable (not ideal, but at least
> > > > usable) for python projects without having to manage PYTHONPATHs or
> do
> > > > whacky stuff like running files with python -m or put even whackier
> > > > boilerplate at the top of every file. And all it requires is 'import
> > > > imsanity' at the top of every file. You can put it in a macro or even
> > just
> > > > type it because it's short and easy to remember.
> > > > >
> > > > > My question is: is this crazy? Please tell me there's a better way
> > and I
> > > > just wasted my time creating this package. There's nothing I'd like
> to
> > hear
> > > > more.
> > > >
> > > > Well, anything that makes you type "import imsanity" at the top of
> > > > every script MUST be crazy. :) I don't know about the actual
> > > > content/purpose though. Good luck with it!
> > > >
> > > > ChrisA
> > > > --
> > > > https://mail.python.org/mailman/listinfo/python-list
> > > >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Sivan Greenberg
Co founder & CTO
Vitakka Consulting

[toc] | [prev] | [next] | [standalone]

#102625

in sake of providing another example, as I ran into the same problem and
fixed it the very same way, one can also take a look at:
(this is the main executable)
https://github.com/sivang/navistore/blob/master/navistore/backend/nhttpserver.py

Note the explicit imports in lines 19-22 to allow the executable finding
modules within the OS instance's site-packages structure.

Here's is Navistore's setup.py for reference (I actually use this project
as a study project in a Python course for programmers I'm running):
- https://github.com/sivang/navistore/blob/master/setup.py

You may find this to be helpful:
- https://pythonhosted.org/setuptools/setuptools.html#using-find-packages

To make Navistore's main executable be avail at command line I used this:
-
http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html

On Sun, Feb 7, 2016 at 8:34 AM, Kevin Conway <kevinjacobconway@gmail.com>
wrote:

> > My question is: is this crazy? Please tell me there's a better way and I
> just wasted my time creating this package.
>
> There is a better way and you have wasted your time creating this package.
>
> I hear your problem statement as asking two questions. The first is: What
> is the right way to include executable content in my Python project? The
> second is: How do I expose executable content from a Python project?
>
> As to the first question, from your project README:
> > Say you have a python project (not a package), with the following
> structure:
>
> All Python code that you want to install and make available in any form,
> import or executable, _must_ be contained within a Python package.
> Organizing Python code in any way other than Python packages will result in
> the challenges you have described. The correct way to include executable
> content is to place the Python code within the package structure. It should
> not be put in other directories within the repository root.
>
> As to the second question, once all Python code is contained within a
> package that can be installed you can use setuptools entry points to expose
> the executable code. The setup() function from setuptools that is used to
> create setup.py files has an argument called 'entry_points' that allows you
> to expose executable content over the command line. See [1] and [2] for
> more details.
>
> Feel free to reach out to me off-list if you have a specific project you
> need advice on. The rules for organizing and packaging Python code aren't
> complex but they tend to cause new Python developers to stumble at first. A
> general rule I give everyone when talking about packaging or importing
> code: If you have to modify sys.path to makes something work then you have
> most certainly made a mistake.
>
> [1]
>
> https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
> [2]
>
> http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html#the-console-scripts-entry-point
>
>
> On Sat, Feb 6, 2016 at 8:54 PM Chris Angelico <rosuav@gmail.com> wrote:
>
> > On Sun, Feb 7, 2016 at 1:47 PM,  <dimva13@gmail.com> wrote:
> > > Imsanity allows you to make imports usable (not ideal, but at least
> > usable) for python projects without having to manage PYTHONPATHs or do
> > whacky stuff like running files with python -m or put even whackier
> > boilerplate at the top of every file. And all it requires is 'import
> > imsanity' at the top of every file. You can put it in a macro or even
> just
> > type it because it's short and easy to remember.
> > >
> > > My question is: is this crazy? Please tell me there's a better way and
> I
> > just wasted my time creating this package. There's nothing I'd like to
> hear
> > more.
> >
> > Well, anything that makes you type "import imsanity" at the top of
> > every script MUST be crazy. :) I don't know about the actual
> > content/purpose though. Good luck with it!
> >
> > ChrisA
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Sivan Greenberg
Co founder & CTO
Vitakka Consulting

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web